Privacy Policy

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events, and any earlier email address of yours recorded when you changed it.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (hello@, support@, privacy@, abuse@, bugs@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.9. Date: 2026-10-22.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events, and any earlier email address of yours recorded when you changed it.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (hello@, support@, privacy@, abuse@, bugs@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.8. Date: 2026-10-16.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events, and any earlier email address of yours recorded when you changed it.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.8. Date: 2026-10-16.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (hello@, support@, privacy@, abuse@, bugs@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.8. Date: 2026-10-16.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.8. Date: 2026-10-16.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events, and any earlier email address of yours recorded when you changed it.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.8. Date: 2026-10-16.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.7. Date: 2026-10-15.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.7. Date: 2026-10-14.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. Apart from Cloudflare passing each request through, as it does for all of hearthmoot.com, no third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which an hourly job erases within about an hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. If our hosting provider's whole-server backups are enabled, copies can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.6. Date: 2026-10-14.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. No third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which are erased within the hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. Copies in our hosting provider's whole-server backups can last up to seven days longer. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.6. Date: 2026-10-14.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies, local storage and website statistics

We use a small number of strictly necessary cookies and some browser local storage. The campaign apps and your account pages contain no analytics, tracking, advertising, session-recording or A/B-testing tooling of any kind. The public hearthmoot.com website counts its visits with a statistics tool we run ourselves, described at the end of this section; it sets no cookie. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and neither the apps nor the website show a cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Website statistics. The statistics run only on the hearthmoot.com website, never in the campaign apps or on your account pages. We use Umami, an open-source tool, on our own server at Hetzner in Helsinki. No third party receives what it collects, so it adds no subprocessor (section 8.2). The legal basis is our legitimate interest in knowing how many people visit the website, where they come from and which of its buttons they use (art. 6(1)(f)).

For each page view, and each click on a button we have named for counting, we store one record: the time, the page address without anything after a "?", the page title, the website's own host name, the domain and path of the page that linked to it, any utm_ campaign tags that link carried, and the name of the button with any fixed label set on it in the website's code.

For each visitor on each day we store one record: browser, operating system, type of device, screen size, browser language and country. Visits are tied together only within one day. The key that links them is replaced every day, so the same browser on another day cannot be linked to it.

What it never stores: your IP address, which is used in memory to work out that day's key and is never written down; your region or city; the rest of a page address after the "?" or any ad click identifier, which are erased within the hour; any name, email address or account; recordings of your visit, heatmaps or page performance timings. The script sets no cookie and writes nothing to your browser's storage. It reads one key, umami.disabled (in the table above), which exists only if you set it yourself to opt out.

If your browser sends a Do Not Track or Global Privacy Control signal, nothing is counted.

The records are kept for 12 months and then deleted. Only we can see them.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.6. Date: 2026-10-14.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it. On erasure that log also loses the network addresses recorded on sign-in, sign-out, signup, passphrase reset, passphrase change and two-step sign-in events.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.6. Date: 2026-10-14.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it, including the network addresses we recorded when you signed in or changed your sign-in details.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.6. Date: 2026-10-14.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. After that your data exists only in encrypted backups, which we do not restore on request. What ends those backups is the key. Each campaign's backups are encrypted with a key of its own, and that key is destroyed automatically by day 90: the key itself on day 70, and the last of our own database backups that held a copy of it before day 90. From then on every remaining copy of the campaign's backups is permanently unreadable, wherever it is stored. At day 90 we also mark the encrypted archives themselves for removal from backup storage. That removal is housekeeping done by a person, and nothing in this policy depends on when it happens.

Accounts that are no longer used. Your account itself, with your email address and sign-in details, outlives your campaigns: you can come back and subscribe again. It does not outlive them indefinitely. When an account has had no subscription and no campaign for 12 months, and nobody has signed in to it in that time, we erase it in the same way as if you had asked us to (section 10.1). The 12 months run from the last sign of use: the end of your last subscription, the day-90 purge of your last campaign, your last sign-in, or the day you signed up, whichever is latest. We email you 30 days before; signing in before the date in that email keeps the account. What an erasure keeps, and why, is the same as for one you ask for: invoices and tax records for 7 years, and our own log of what was done to your account with your identity removed from it.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.5. Date: 2026-10-09.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. Backups run on a rolling cycle and complete their purge by 90 days; between those two dates your data exists only in encrypted backups that the Service cannot reach and that we do not restore on request. At day 90 the per-tenant backup key is destroyed as part of the purge, which makes any remaining archive copy permanently unreadable.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which stores them in Europe (Workspace data regions); any processing outside Europe is under Google's SCCs, and the mailbox sees only the email of anyone who writes to those addresses. One exception: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.4. Date: 2026-10-07.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. Backups run on a rolling cycle and complete their purge by 90 days; between those two dates your data exists only in encrypted backups that the Service cannot reach and that we do not restore on request. At day 90 the per-tenant backup key is destroyed as part of the purge, which makes any remaining archive copy permanently unreadable.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Three exceptions. Our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which is global under Google's SCCs and sees only the email of anyone who writes to those addresses. And our operator uses Anthropic's AI assistant, Claude, to answer support email and to run the Service: what it reads during that work, which can include the content of a support email and, while it works on our servers, tenant data, is processed by Anthropic in the United States under the EU Standard Contractual Clauses in Anthropic's data processing terms. Nothing is stored there for us, and Anthropic does not use it to train its models.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. You have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. This applies to every customer, wherever you live. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.3. Date: 2026-10-04.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Opening your content through the Service happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to. Our operators also log in to the servers themselves to run, repair and back up the Service; that maintenance access is not logged campaign by campaign.

4.3 Honest encryption language. Traffic between your browser and our servers is encrypted (TLS); between our own servers it travels over our hosting provider's private network, which we do not separately encrypt. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. Backups run on a rolling cycle and complete their purge by 90 days; between those two dates your data exists only in encrypted backups that the Service cannot reach and that we do not restore on request. At day 90 the per-tenant backup key is destroyed as part of the purge, which makes any remaining archive copy permanently unreadable.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS between your browser and our servers; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki); error reporting uses Sentry's EU region. We chose this to keep your stored data out of international transfers rather than manage them with contractual mechanisms. Three exceptions. Our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered. Our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which is global under Google's SCCs and sees only the email of anyone who writes to those addresses. And our operator uses Anthropic's AI assistant, Claude, to answer support email and to run the Service: what it reads during that work, which can include the content of a support email and, while it works on our servers, tenant data, is processed by Anthropic in the United States under the EU Standard Contractual Clauses in Anthropic's data processing terms. Nothing is stored there for us, and Anthropic does not use it to train its models.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/legal/subprocessors/. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. As an EU consumer you have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

Checkout. When you subscribe, the payment step loads Paddle's own checkout script (Paddle.js, from cdn.paddle.com). Paddle is the merchant of record and an independent controller for what that step collects; its privacy policy, not this one, governs it.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.2. Date: 2026-10-02.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Access to your content happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to.

4.3 Honest encryption language. Your data is encrypted in transit. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. Backups run on a rolling cycle and complete their purge by 90 days; between those two dates your data exists only in encrypted backups that the Service cannot reach and that we do not restore on request. At day 90 the per-tenant backup key is destroyed as part of the purge, which makes any remaining archive copy permanently unreadable.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS in transit; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data stays in the EEA. Hosting is in Germany (Falkenstein) and Finland (Helsinki); error reporting uses Sentry's EU region. We chose this to remove the international transfer question rather than manage it with contractual mechanisms. Two exceptions, and neither touches your campaign data: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered; and our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which is global under Google's SCCs and sees only the email of anyone who writes to those addresses, never tenant content.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/subprocessors. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. As an EU consumer you have 14 days from the start of a paid subscription to withdraw without giving reasons, and we then refund the payment in full. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. At the checkout you tick a box confirming that you are 18 or older and that you want the campaign to start straight away; we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.1. Date: 2026-09-30.

This policy explains what personal data is involved when you use Hearthmoot, and what we do and do not do with it. Hearthmoot is operated by Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands, KVK 42144788 ("we", "us"). Contact: [email protected].

This policy covers the hosted service, which we run for you.

1. Two roles at once

On the hosted service we hold both GDPR roles, and which one applies depends on the data:

We say this plainly because it decides who you go to with a request. For your own account data, come to us. For your players' data, your players come to you, and we help you answer them (section 10.3).

If your table is a private social circle, GDPR's household exemption (art. 2(2)(c)) may mean you carry no controller obligations at all. Running paid games, or a group that is not a private social circle, will usually take you outside it.

2. What we collect as controller (your account)

We do not use your data for marketing without separate consent, do not sell it, and do not share it beyond the parties named in section 8.

3. What is in your tenant, where we are processor

3.1 Whatever you and your players put there: character sheets, session notes, wiki pages, maps, house rules, and player display names. You decide what goes in. We process it only to run the Service for you (see Data Processing Agreement).

3.2 Technical data generated by use, such as access logs and error reports, which we process for security and reliability.

3.3 We deliberately do not collect player email addresses. Players join your tenant with a display name and a passcode you issue. There is no player account with us, no player mailing list, and no player identity we could link across tenants. This came from a design decision made before hosting existed, it is a genuine privacy advantage, and we intend to keep it.

4. What we do not do with your content

These are commitments, not descriptions of current practice we might quietly change.

4.1 No content scanning. We do not index your content into any shared or cross-tenant search, run analytics on page bodies, inspect content automatically, or train any model on it. Under the EU Digital Services Act art. 8 we are under no general obligation to monitor what you store, and we do not.

4.2 No routine access. Our staff do not browse tenant vaults. Access to your content happens only when a support ticket requires it, is written to an audit log, and you are notified that it happened. That notification is the part you can hold us to.

4.3 Honest encryption language. Your data is encrypted in transit. At rest, your nightly backup archive is encrypted — the live storage volume and database behind your campaign are not separately encrypted at rest, a deliberate scope decision as of 2026-08-13, not an oversight. Encryption at rest is a real security measure and it protects against someone stealing or improperly disposing of a disk; what stands in its place for the volume and database is where your data actually lives: Hetzner's data centres hold ISO 27001 certification for physical and infrastructure controls, and section 4.2's break-glass regime bounds who can reach it. We revisit this if paid legal advice says the gap is unacceptable for the risk, or on the first complaint involving sensitive content, whichever comes first.

It does not mean we are unable to read your content, and we will not tell you that it does. The Service has to parse your markdown on the server to build your wiki, resolve rules, run search, and read statblocks. A service that genuinely could not read your content would have to do all of that in your browser, which would be a different product. Anything marketed as "zero-knowledge" in this space is encryption at rest under a better name. What actually limits our access is section 4.2, which is a control we can show you evidence of.

5. Where the terms live

5.1 The art. 28 processor terms are in a separate Data Processing Agreement, incorporated into the Subscription Terms and accepted at signup. It sets out our instructions, confidentiality, security, subprocessors, breach handling, deletion, and audit.

5.2 Acceptable use and the notice-and-action route for reporting unlawful content are in Acceptable Use Policy.

6. How long we keep things, including backups

When a subscription ends, for any reason:

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination instead. Retries have no fixed length and nothing is deleted while they run, so the retention clock starts on the day you stop being a customer. Subscription Terms §8 is the full statement.

Deletion at 60 days removes your data from live systems and is irreversible. Backups run on a rolling cycle and complete their purge by 90 days; between those two dates your data exists only in encrypted backups that the Service cannot reach and that we do not restore on request. At day 90 the per-tenant backup key is destroyed as part of the purge, which makes any remaining archive copy permanently unreadable.

Accounting records are kept for 7 years because Dutch tax law requires it, separately from your campaign data.

Server and access logs (section 2) are bounded by size rather than by date. Each log file is held to a fixed size and to a fixed number of files, and the oldest entries are deleted once that ceiling is reached. How long any single entry survives therefore depends on how much traffic the system carrying it sees: a busy one turns its log over in days, a quiet one holds older entries inside the same ceiling. We do not state a number of days here, because no timer enforces one and we would rather tell you the limit that runs than publish a period we do not keep to.

A smaller stream sits outside that ceiling. The software that runs your account writes diagnostic output so that failures can be investigated, and nothing prunes that output on a schedule; it is cleared by hand. It holds no record of individual requests. The personal data it can contain is an account email address quoted inside an error message.

7. Security (art. 32)

7.1 Encryption. TLS in transit; backup archives encrypted at rest. Storage volumes and tenant databases are not separately encrypted at rest — described honestly, with what stands in its place and the revisit trigger, in section 4.3.

7.2 Tenant isolation. One tenant is one campaign with its own database and its own vault volume. Databases are never merged across tenants.

7.3 Access control. Named accounts, no shared administrative credentials, key-based SSH, least privilege, and the break-glass regime in section 4.2 with its audit log.

7.3a Two-step sign-in. You can switch on a second factor for your account from your security page, using any authenticator app. It is offered, never required.

Your backup codes are stored as one-way hashes and cannot be recovered by anyone, including us — which is why we show them to you once and cannot show them again. Your authenticator secret is different, and we would rather say so plainly than imply more: checking the six digits your app produces requires the secret itself, so it is stored encrypted under a key that is held outside the database rather than hashed. A copy of the database on its own does not yield it.

There is deliberately no reset by email. A second factor you could switch off from your inbox would be worth no more than your mailbox password, which is the protection it exists to add. If you lose both your phone and your backup codes, we can clear the second factor for you after we have dealt with you through support; the act that clears it also writes an access record and sends you a notice saying it happened, quoting the reason. Clearing it never signs anyone in — you then use your passphrase, and set two-step sign-in up again when you are ready.

7.4 Backups. Scheduled per-tenant snapshots held off the serving host, encrypted, retained to match the 90-day purge, with restore tested by drill rather than assumed.

7.5 Breach notification. If a personal data breach happens:

• Where we are processor (your campaign data), we notify you without undue delay, with an internal target of 24 hours from confirmation, so that you have time inside your own 72-hour clock. You then decide whether to notify your supervisory authority and your players.
• Where we are controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it, and we tell affected users directly where art. 34 requires it.

Our internal procedure is written and kept current in a written breach procedure, before an incident rather than during one.

8. Who else is involved

8.1 Data residency: tenant data stays in the EEA. Hosting is in Germany (Falkenstein) and Finland (Helsinki); error reporting uses Sentry's EU region. We chose this to remove the international transfer question rather than manage it with contractual mechanisms. Two exceptions, and neither touches your campaign data: our uptime monitoring and status page run on Better Stack in the United States, which only ever learns whether our own public addresses answered; and our support and role mailboxes (support@, privacy@, abuse@) run on Google Workspace, which is global under Google's SCCs and sees only the email of anyone who writes to those addresses, never tenant content.

8.2 Subprocessors. The current list, with purpose and location for each, is published at Subprocessors list and at hearthmoot.com/subprocessors. At the date of this policy:

We give at least 30 days' notice by email before adding or replacing a subprocessor, and customers may object on data-protection grounds (Data Processing Agreement §6).

8.3 Paddle is our merchant of record and an independent controller for payment data. It sells the subscription to you, takes the payment, and handles tax and invoicing. We never see or store your card details. Paddle's own privacy policy governs that processing, and it is not our subprocessor.

9. Record of processing activities

We maintain a record of processing activities under art. 30, covering both our controller and processor roles.

The art. 30(5) exemption for organisations under 250 staff does not apply to us, because this processing is regular rather than occasional. That exemption is commonly misread, and we would rather state why it does not help us than rely on it. The record is available to the supervisory authority on request and to customers as part of the audit route in Data Processing Agreement §12.

10. Your rights

10.1 Toward us, for your account data (section 2): access, rectification, erasure except records we must keep by law, restriction, objection, and portability. Contact [email protected]. We respond within one month.

10.2 Portability and access to your campaign content is self-service and immediate. Export gives you the complete markdown vault plus a database export, in the format the data went in, at any time while your subscription runs and throughout the 30-day retention window after it ends. You do not have to ask us and we do not gate it.

A paused campaign stops serving, so during the retention window the download comes from your Hearthmoot account page rather than from the campaign itself. It is the same content, it is still one click, and we do not read your campaign to produce it.

10.3 If you are a player, the controller for your data is the DM whose tenant you joined, not us. Ask them. If you contact us instead we will not act on the substance, because it is not our data to act on; we will tell you to contact the DM and, where we can identify the tenant, we tell the DM that a request arrived.

10.4 You may complain to the Autoriteit Persoonsgegevens (autoriteitpersoonsgegevens.nl) or to the supervisory authority where you live.

11. Subscriptions, withdrawal, and cancellation

11.1 14-day right of withdrawal. As an EU consumer you have 14 days from the start of a paid subscription to withdraw without giving reasons. Because the trial is free and requires no card, most subscriptions start only after you have already used the Service. Where you asked us to begin during the withdrawal period, you pay only for what was supplied before you told us. You make that request by ticking a box at the checkout, and we keep a record of the exact wording you agreed to and the date — see section 2.

11.2 Cancellation is self-service. You can cancel from your account or from your Paddle receipt, at any time, effective at the end of the period you have paid for. There is no cancellation fee, no notice period, and no requirement to talk to anybody. What happens to your data afterwards is section 6.

11.3 Refunds are processed by Paddle as merchant of record.

Full terms: Subscription Terms.

12. Cookies and local storage

We use a small number of strictly necessary cookies and some browser local storage. The product contains no analytics, tracking, advertising, session-recording, or A/B-testing tooling of any kind — verified across the Wiki, Tracker, Control plane and shared packages. Because every cookie we set is strictly necessary to provide a service you asked for, none of them requires consent under the ePrivacy Directive, and the apps show no cookie banner. This section is the transparency disclosure that art. 13 requires even where no consent is owed.

Cookies (all strictly necessary):

Local and session storage (preference and interface state, exempt from consent):

None of these is used to profile you or to track you across sites, and none is shared with a third party.

13. Changes to this policy

We publish material changes and notify the email on file where the change affects you. Previous versions stay available so you can see what changed and when. The date below identifies the current version.

Version: 1.0. Date: 2026-09-30.