Jotholm Privacy Policy
Last updated: 18 July 2026
Effective: 21 June 2026
1. Who we are (the data controller)
Jotholm ("Jotholm", "we", "us") is a subscription software-as-a-service collaborative whiteboard. This policy explains what personal data we process, why, on what lawful basis, how long we keep it, and the rights you have over it.
The data controller is:
- Controller: Johan Sjölin, a natural person operating as a sole trader (Swedish enskild näringsidkare), trading as Jotholm (jotholm.io), established in Sweden. As a sole trader there is no separate company legal entity and no corporate registration number; the business is conducted under the founder's own name.
- Registered / contact address: Trollhasselgatan 27, 417 11 Göteborg, Sweden.
- Country of establishment: Sweden (EU/EEA).
- Privacy / data-protection contact: privacy@jotholm.io (see Jotholm GDPR & DSR Process); general legal contact legal@jotholm.io.
- Data Protection Officer: none appointed. A DPO is not required, as none of the GDPR Art. 37 triggers apply (large-scale systematic monitoring, large-scale special-category processing, or public-authority status). No EU Art. 27 representative is required, since the controller is established in the EU (Sweden).
2. What personal data we collect
We practise data minimisation (GDPR Art. 5(1)(c)): we collect only what each purpose requires.
2.1 Account data
When you create an account we store:
- Email address (used as your login identity; stored normalised/lower-cased and unique).
- Display name and a profile colour.
- Authentication credential: either a password hash (argon2id; we never store your plaintext password) or, if you sign in with Google, a Google account identifier ("sub") and the provider name instead of a password.
- Account timestamps: account-created time and email-verification time.
- Administrator flag (internal, set only for operator accounts on an allowlist).
2.2 Workspace and board content
Jotholm is a whiteboard. Content you and your collaborators create (stickers, frames, text blocks, uploaded images, board layout, and your per-user board viewport) is stored per workspace, along with the identifier and timestamp of the member who created or last changed each element. A full mutation history ("ops log") is retained for collaboration, undo, and recovery (retention in §5).
2.3 Session and device data
When you sign in we create session records containing a hashed session token, timestamps, and a device label derived from your browser's User-Agent string (truncated). Session cookies are described in the Cookie Policy.
2.4 Billing data
If you subscribe to a paid plan, billing is handled by Stripe (see §7 and the Subprocessors list). We store a Stripe customer identifier against your account and a Stripe subscription identifier, status, and renewal date against the relevant workspace. We do not store your card number or full payment details; those are handled directly by Stripe.
2.5 Email-flow data
For email verification and magic sign-in links we temporarily store hashed, expiring tokens tied to your email address.
2.6 What we do not collect
- We do not persist general web-server access logs, request paths, or stored IP-address logs. General access logging is not enabled, so no general client-IP log lines or request-path logs are recorded or retained, and there is no general access-log retention period to disclose. The one narrow exception is the authentication-security event store described in §2.7 below: login outcomes recorded with a pseudonymised (HMAC) identifier and the source IP, kept inside your own workspace database under the retention caps in §5. Outside that store, IP addresses are used only transiently, in memory, for rate-limiting and abuse-prevention and are not written to durable storage; no email, name, or User-Agent is retained outside the application.
- Our internal product analytics record only closed-enum event counts and a workspace identifier: no IP address, no User-Agent, no email, no name.
- We use no third-party advertising, marketing, profiling, session-replay, or cross-site tracking technologies.
2.7 Authentication-security event data
To help our operator diagnose login failures and detect attacks on your account (for example, bursts of failed sign-ins), we keep a bounded record of authentication outcomes inside your own workspace database. Each record contains only:
- a pseudonymised login identifier: a keyed one-way HMAC of the (lower-cased) email used to sign in. The raw email is never stored in this record, and the value cannot be reversed to an email without our server-held secret key;
- the source IP address (last network hop);
- the outcome (success/failure) and a fixed reason code drawn from a closed list; and
- a timestamp.
There is no password, token, cookie, or free-text field, and no raw email or name. This store is retention-bounded (newest 20 records per identifier, a 30-day maximum age, and a hard 10,000-record cap per workspace; see §5), self-expiring, lives only inside your own per-workspace database (no cross-tenant store), and is readable only through our restricted, audited operator back-office (§8). It is not used for analytics, profiling, marketing, or any automated decision-making.
3. Why we process it, and our lawful basis
Every processing activity maps to a GDPR Art. 6 lawful basis:
| Purpose | Data used | Lawful basis (Art. 6) |
|---|---|---|
| Create and operate your account; provide the whiteboard service | Account, workspace/board content, session | Contract (Art. 6(1)(b)) |
| Authenticate you and keep your account secure | Credentials, session, device label | Contract (Art. 6(1)(b)); Legitimate interests (Art. 6(1)(f), security) |
| Rate-limiting and abuse/fraud prevention | Transient IP address | Legitimate interests (Art. 6(1)(f)) |
| Diagnose login failures and detect account-security attacks (authentication-security events, §2.7) | Pseudonymised (HMAC) login identifier, source IP, login outcome | Legitimate interests (Art. 6(1)(f), security) |
| Process subscription payments and renewals | Email, Stripe identifiers, plan status | Contract (Art. 6(1)(b)) |
| Send service/transactional emails (verification, sign-in, account notices) | Contract (Art. 6(1)(b)) | |
| Maintain product analytics to improve the service | Aggregated, non-identifying event counts | Legitimate interests (Art. 6(1)(f)) |
| Comply with legal/accounting/tax obligations | Billing records | Legal obligation (Art. 6(1)(c)) |
We do not currently rely on consent (Art. 6(1)(a)) for any of the above, because we do not run non-essential cookies or marketing. There is no marketing-email programme at launch; we send only transactional/service email (account, billing, security, and policy-change notices). If a marketing-email programme is introduced later, it will require a separate, freely-given opt-in and an update to this section.
Purpose limitation (Art. 5(1)(b)): we use personal data only for the purposes listed above and disclosed at collection.
4. Who we share it with (subprocessors & recipients)
We do not sell personal data. We share it only with vendors that process data on our behalf under contract. The complete, current list, with each vendor's purpose and location, is maintained in the Jotholm Subprocessors list. In summary, personal data may be processed by our payment processor (Stripe), our transactional email provider, our hosting/infrastructure provider, and, only if you choose "Sign in with Google", Google as the identity provider.
We may also disclose data where legally required (e.g. valid legal process), which we will assess against applicable law before complying.
5. How long we keep it (retention & deletion)
We keep personal data only as long as needed for the purpose, then delete it. Current retention rules in the system:
| Data category | Retention | Deletion trigger |
|---|---|---|
| Account, workspace membership, board content | For the life of the account/workspace | Account or workspace deletion (§6) |
| Board mutation history ("ops log") | Free plan: 7 days; Paid plan: 90 days (newest ~2,000 changes always kept) | Automatic daily housekeeping |
| Recycle bin (soft-deleted stickers/frames) | 14 days | Automatic hard-delete after retention |
| Account ("front-door") sessions | 30 days (sliding) | Expiry / sign-out / housekeeping |
| Workspace sessions | 365 days (sliding) | Expiry / sign-out / housekeeping |
| Email verification / magic-link tokens | Short-lived (verification ~24h; magic link ~15 min) | Expiry / consumption |
| Authentication-security events (§2.7): pseudonymised (HMAC) identifier, source IP, login outcome | Newest 20 records per identifier, 30-day maximum age, and a 10,000-record hard cap per workspace (whichever bound is hit first) | Automatic pruning on each write and on a daily housekeeping run (self-expiring) |
| Unverified accounts | Reaped after the verification window (~24h) | Automatic housekeeping |
| Stripe webhook event records (idempotency) | 45 days | Automatic housekeeping |
| Billing/tax records | 7 years after the end of the financial year (Swedish Bookkeeping Act, Bokföringslag 1999:1078) | Legal obligation |
| Dormant free workspaces (cold-archive) | Inactive ~12 months (365 days) → 30-day warning/grace → board content tarred off hot storage to on-premises backup storage (restorable on next access) → archived tarball pruned after a further 180 days. | Automatic housekeeping |
The cold-archive lifecycle is enabled in production; a dormant free workspace is warned, then archived after the grace period, then permanently removed once the 180-day tarball window elapses.
Backups: Operational backups are taken hourly as per-workspace database snapshots plus a content-addressed copy of uploaded images, written to separate backup storage held apart from the live system. They are retained on a rolling grandfather-father-son schedule: every hourly snapshot for 24 hours, one per day for 7 days, and one per week for 8 weeks, so the maximum time any copy of your data persists in a backup is approximately 8 weeks. Backups are held on access-controlled storage, encrypted at rest; the primary backup store is on-premises in Sweden (EU/EEA). See §6 for how this interacts with erasure.
6. Your rights (data-subject rights)
If you are in the EEA/UK you have the following rights under the GDPR/UK GDPR. Jotholm has built self-service tooling behind several of these:
- Access: get a copy of your data. Self-service export is available (account data plus every workspace you belong to, including full board history and an asset manifest), and you can also request it via our privacy contact.
- Rectification: correct inaccurate data. You can edit your display name and profile in-product; email/identity changes via our privacy contact.
- Erasure ("right to be forgotten"): self-service account deletion synchronously hard-deletes your account and all data you solely own (workspaces, board content, uploads, sessions, email tokens), drops your memberships in shared workspaces, and cancels any active subscription. Billing records held by our payment processor (Stripe) are retained for the statutory accounting-retention period (see §5, Billing/tax records) and are not deleted, because we are legally required to keep them (Swedish Bookkeeping Act). Erasure is free on every tier and is never paywalled. Caveat: deleted records are purged from live systems immediately, but residual copies persist in point-in-time backups (held on encrypted, access-controlled backup storage; see §5) until they expire on the rolling backup cycle (maximum ~8 weeks, §5). Erasure is not retro-actively propagated into existing backup snapshots, and we keep no exclude-on-restore list. In the rare event of a disaster-recovery restore, records erased after a snapshot was taken would briefly reappear, and are re-purged on the next housekeeping run.
- Restriction: ask us to limit processing. Request via our privacy contact.
- Portability: receive your data in a structured, machine-readable format. Our export is JSON (
jotholm-account-export), satisfying portability. - Objection: object to processing based on legitimate interests. Request via our privacy contact.
- Rights related to automated decision-making: we do not carry out solely-automated decision-making or profiling with legal or significant effects.
- Withdraw consent: where processing is based on consent (none at present), you can withdraw it at any time.
How to exercise them, identity verification, and our response SLA are set out in the Jotholm GDPR & DSR Process. You also have the right to lodge a complaint with a supervisory authority; our lead authority is the Swedish Authority for Privacy Protection (Integritetsskyddsmyndigheten, "IMY"), and you may also complain to the supervisory authority in your own country of residence.
7. International transfers
Your core workspace data is stored within the EU/EEA (see hosting, below). Some personal data is processed by subprocessors located in the United States (payments and transactional email); for those transfers we rely on an appropriate cross-border transfer mechanism (Standard Contractual Clauses and the providers' Data Processing Agreements).
- Primary hosting / data-storage location: Jotholm is self-hosted on-premises in Sweden on a privately-operated cluster, not a named public cloud. All live workspace databases, uploaded images, and cold-archive tarballs reside physically in Sweden, an EU/EEA member state, as does the primary backup store. GDPR applies directly to this processing.
- Stripe (US/IE): Stripe is our sole payment processor; we share only your email and account/workspace identifiers (as metadata). Stripe's standard Data Processing Agreement and Standard Contractual Clauses are incorporated by reference into its Services Agreement and apply to our account. The contracting entity is Stripe, Inc. (US) and/or Stripe Payments Europe, Ltd. (Ireland), with Stripe's standard SCCs in place.
- Transactional email provider (US): Our email provider is Resend, which processes the recipient email address and message content in the United States under its standard DPA (incorporating SCCs).
- Google "Sign in with Google" / OIDC (US), an independent controller, not a Jotholm subprocessor: Optional; only where a user chooses Google sign-in. That user authenticates directly with Google under Google's own terms and privacy policy, and Jotholm then receives back verified identity attributes (email, name, Google subject id). For this authentication Google acts as a separate (independent) controller, not as a processor acting on Jotholm's instructions, so Jotholm makes no controller-to-processor transfer to Google and sends Google no personal data about other users. Google's own cross-border safeguards (Google's EU–US Data Privacy Framework certification and/or the SCCs in Google's terms) govern Google's US processing.
In summary, the cross-border (non-EEA) data flows described above are to the US-based processors Stripe and Resend (each covered by its standard DPA incorporating SCCs, Stripe under the dual-entity arrangement below) and, for users who choose it, Google sign-in, where Google is an independent controller governed by its own DPF/SCC safeguards rather than a Jotholm processor transfer. For Stripe the contracting entity is Stripe, Inc. (US) and/or Stripe Payments Europe, Ltd. (Ireland), with Stripe's standard SCCs in place. Transfer-mechanism characterisation: Stripe: SCCs via Stripe's standard DPA (dual-entity); Resend: SCCs via Resend's standard DPA; Google sign-in: independent controller under Google's own DPF/SCC safeguards.
8. How we protect your data
The following technical and organisational measures are in place, with their limits noted:
- Credentials & tokens: passwords are stored only as argon2id hashes (never plaintext); session and email-link tokens are stored hashed.
- Pseudonymised security logging: the durable authentication-outcome store (§2.7) keys each record by a secret-keyed HMAC of the login identifier, never the raw email, so the stored security log cannot be read back to an email address without our server-held key; it is held under strict retention caps (§5).
- Tenant isolation: each workspace's data lives in its own separate database file; production data is accessible only to the operator.
- Encryption in transit: all traffic is served over TLS 1.2+ using certificates from a public certificate authority.
- Encryption at rest: workspace databases and uploaded images are held on volume-level-encrypted storage. This covers the primary live copy on the application cluster and the primary backup and cold-archive copies, which are held on access-controlled on-premises systems in Sweden (EU/EEA). This is full-volume (storage-layer) encryption: it protects the data on the physical media (for example, against loss or theft of a disk) and is complemented by physical security and access control; it is not per-tenant, application-layer encryption. We consider our at-rest and in-transit protections proportionate to the nature of the data and the deployment (GDPR Art. 32 is risk-based).
- Administrative access: operator/administrative access to the back-office is tightly restricted, gated behind authenticated single-sign-on limited to an explicit operator allow-list, with an independent server-side identity check and an append-only audit log of every administrative read; the system fails closed (denies access) if identity cannot be verified.
- Operational hygiene: application secrets are held in encrypted secret storage and are never placed in source code, logs, or URLs; application services run with least-privilege (non-root) containers; and changes pass automated quality and security checks before release.
9. Personal data breaches
In the event of a personal-data breach we will assess it and, where required, notify the competent supervisory authority (the Swedish IMY) within 72 hours of becoming aware, and notify affected individuals without undue delay where the breach is likely to result in a high risk to their rights (GDPR Arts. 33–34). The breach-notification owner is the founder and controller (there is no DPO).
We maintain operational monitoring and alerting, in-app authentication rate-limiting, a bounded durable record of authentication outcomes (§2.7), and an append-only administrative audit trail to help us identify and investigate suspected security incidents. If we become aware of a personal-data breach, the assessment and notification commitments set out above apply.
10. Children
Jotholm is not directed to children. The minimum age of use is 16. We do not rely on a child-consent basis (account holders are adults; our lawful bases are contract and legitimate interests), so the Art. 8 parental-consent machinery does not apply. There is currently no automated age-gate at sign-up; by creating an account you confirm you are at least 16.
11. Cookies
We use only a small number of strictly-necessary cookies for sign-in and security; we set no advertising or analytics cookies. Full detail is in the Jotholm Cookie Policy.
12. Changes to this policy
We may update this policy; updates are notified by in-product notice, and material changes additionally by email, with reasonable advance notice before they take effect. The "Last updated" date reflects the current version.