Data Processing Agreement (GDPR art. 28)

@@ -61,12 +61,13 @@ Two points are stated plainly because they are commonly overstated in this marke
    that it does.** The Service must parse markdown server-side to build the wiki, resolve rules,
    and run search. A "zero-knowledge" architecture is not possible for this product and we will
    not describe it as one. What limits our access is the break-glass control in Annex C.4:
-   access only on a support ticket, logged, with you notified that it happened.
+   opening your content through the Service only on a support ticket, logged, with you notified
+   that it happened.
 
 ## 6. Subprocessors
 
 1. You give **general authorisation** for us to engage subprocessors. The current list is
-   published at `legal/SUBPROCESSORS.md` and maintained at hearthmoot.com/subprocessors.
+   published at `legal/SUBPROCESSORS.md` and maintained at hearthmoot.com/legal/subprocessors/.
 2. We give **at least 30 days' notice by email** before adding or replacing a subprocessor. The
    notice goes to your account email address. There is nothing to subscribe to and no way to opt
    out of it: it is part of this agreement rather than a mailing list, so every account holder
@@ -81,13 +82,18 @@ Two points are stated plainly because they are commonly overstated in this marke
 
 ## 7. International transfers
 
-**Tenant data stays in the EEA.** Hosting is in Germany and Finland (Hetzner: Falkenstein,
-Helsinki) and error reporting uses Sentry's EU region.
+**Tenant data is stored in the EEA.** Hosting is in Finland (Hetzner, Helsinki) and error reporting
+uses Sentry's EU region.
 
-The one subprocessor without EU pinning is the business mailbox (Google Workspace), and it holds no
-tenant data: it receives email sent to the support and role addresses, and nothing else. The claim
-above is about tenant CONTENT and is exact — a correspondent's own email is a separate processing
-activity, disclosed in Annex B rather than folded into this sentence.
+The business mailbox (Google Workspace) has no EU pinning, and it holds no tenant data: it receives
+email sent to the support and role addresses, and nothing else. A correspondent's own email is a
+separate processing activity, disclosed in Annex B.
+
+One subprocessor can process tenant data outside the EEA. Our operator uses Anthropic's AI
+assistant, Claude, to run the Service. While it works on our servers, the data it reads, which can
+include tenant content, is processed by Anthropic in the United States. Nothing is stored there for
+us, and the transfer is covered by the EU Standard Contractual Clauses in Anthropic's data
+processing terms.
 
 This is a design decision rather than a transfer-management exercise: it eliminates the
 international transfer question for tenant content instead of solving it with contractual
@@ -175,10 +181,11 @@ with:
    is not available, because tenants are co-located on shared hosts and physical or interactive
    access by one customer would compromise other customers' data. This is a real limit and we
    state it rather than promising an audit we could not permit. Where documentary evidence does
-   not satisfy you, we offer an **inspection of a staging replica**: a host provisioned from the
-   same templates, compose files and hardening steps as production, carrying synthetic tenants,
-   on the notice in item 2 and at our reasonable cost. A replica demonstrates the built posture
-   rather than any live machine, and we say so rather than presenting it as more.
+   not satisfy you, we will, on request, set up an **inspection of a staging replica**: a host
+   provisioned from the same templates, compose files and hardening steps as production, carrying
+   synthetic tenants, on the notice in item 2 and at our reasonable cost. No such host runs
+   permanently; we build one for the inspection. A replica demonstrates the built posture rather
+   than any live machine, and we say so rather than presenting it as more.
 4. Where a supervisory authority requires an inspection we cannot satisfy documentarily, we
    cooperate with the authority directly.
 5. You bear your own audit costs. We may charge our reasonable costs for audits beyond the
@@ -242,12 +249,13 @@ Maintained in full, with purposes and locations, at `legal/SUBPROCESSORS.md`.
 
 | Subprocessor | Purpose | Location of processing |
 |---|---|---|
-| Hetzner Online GmbH | Hosting, compute, storage, backups | Germany (Falkenstein) / Finland (Helsinki) |
+| Hetzner Online GmbH | Hosting, compute, storage, backups | Finland (Helsinki) |
 | Functional Software, Inc. (Sentry), EU region | Error reporting | EU region |
 | Resend, Inc. (EU region) | Transactional email | EU region |
 | Cloudflare, Inc. | DNS, CDN and reverse proxy | Global edge; EEA origin |
 | Better Stack, Inc. | Uptime monitoring of our own public addresses, and the public status page | United States — no tenant content and no customer personal data; EU SCCs in their published DPA |
 | Google Ireland Ltd — Google Workspace | Business mailbox for the support and role addresses (support@, privacy@, abuse@) | Global under Google's SCCs; no EU data-region pinning on the current plan |
+| Anthropic, PBC | AI assistant (Claude) our operator uses for support email and for running the Service; reads what that work touches, which can include tenant content | United States, under the EU SCCs in Anthropic's data processing terms; nothing stored for us; no model training |
 
 **Tenant content never reaches Google Workspace.** It is the company's own mailbox: what it
 processes is the email of whoever writes to those addresses, which is why it is listed here at all.
@@ -259,7 +267,9 @@ Paddle is **not** a subprocessor. It is an independent controller for payment da
 
 # Annex C — Technical and organisational measures (art. 32)
 
-**C.1 Encryption.** TLS for all data in transit. Backup archives are encrypted at rest with
+**C.1 Encryption.** TLS between the customer's browser and our servers. Traffic between our own
+servers travels over the hosting provider's private network and is not separately encrypted.
+Backup archives are encrypted at rest with
 AES-256. **Storage volumes and the live tenant databases are not separately encrypted at rest —
 re-scoped by an explicit 2026-08-13 decision, not an oversight.** What stands in its place: the
 hosting infrastructure (Hetzner) runs in data centres holding ISO 27001 certification for physical
@@ -277,10 +287,11 @@ vault-path jail, database credentials, network, and volumes.
 **C.3 Access control.** Named accounts, no shared administrative credentials, key-based SSH
 only, and least privilege. Secrets are not stored in images, repositories, or logs.
 
-**C.4 Break-glass access to tenant content.** No routine browsing of tenant vaults. Access
-happens only when a support ticket requires it, is recorded in an audit log, and **the tenant is
-notified that it happened**. This is the demonstrable control behind the no-monitoring
-commitment.
+**C.4 Break-glass access to tenant content.** No routine browsing of tenant vaults. Opening tenant
+content through the Service happens only when a support ticket requires it, is recorded in an
+audit log, and **the tenant is notified that it happened**. This is the demonstrable control behind
+the no-monitoring commitment. Operators also log in to the hosts to run, repair and back up the
+Service; that maintenance access is not logged per tenant.
 
 **C.5 No content scanning.** No cross-tenant indexing, no analytics on page bodies, no automated
 inspection, no model training on tenant content.
@@ -307,4 +318,4 @@ re-review after remediation. Measures are reviewed when the architecture changes
 
 ---
 
-*Version: 1.0. Date: 2026-09-30.*
+*Version: 1.1. Date: 2026-10-02.*

This Data Processing Agreement ("DPA") forms part of the Hearthmoot Hosted Subscription Terms between you ("Controller") and Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands ("Processor", "we"). It is accepted when you accept those terms and needs no separate signature.

Where this DPA conflicts with the Subscription Terms on the processing of personal data, this DPA prevails.

1. Roles

1. For campaign data in your tenant — your players' names, characters, session notes, and anything else you or your players enter — you are the Controller and we are the Processor.
2. For your account and billing data we are an independent Controller. That processing is outside this DPA and is described in Privacy Policy.
3. Paddle is an independent Controller for payment data. It is not our subprocessor and we do not direct its processing.
4. If your use of the Service is purely personal or household activity, the GDPR may not apply to you at all (art. 2(2)(c)). This DPA is written so that it works if it does apply. Running paid games, or a table that is not a private social circle, will usually take you outside the household exemption.

2. Subject matter and duration

We process personal data on your behalf only to provide the Service, for as long as your subscription runs, plus the retention window in section 11.

The subject matter, nature and purpose of the processing, the categories of data subject, and the categories of personal data are set out in Annex A.

3. Processing only on documented instructions

1. We process personal data only on your documented instructions, including on transfers to a third country. The Subscription Terms, this DPA, and your use of the Service's features are your documented instructions. No separate instruction form is needed for ordinary use.
2. We tell you if we believe an instruction infringes the GDPR or other EU or Member State data protection law. We may suspend the affected processing until the instruction is resolved.
3. If we are required by EU or Member State law to process beyond your instructions, we inform you of that requirement before processing, unless that law prohibits informing you on important grounds of public interest.
4. We do not process tenant content for any purpose of our own. No content scanning, no analytics on page bodies, no cross-tenant indexing, no model training. This is a commitment under Subscription Terms §9.3 and it applies here as an instruction limit.

4. Confidentiality

Every person we authorise to process personal data is bound by an obligation of confidentiality, whether by contract of employment, contractor agreement, or statutory duty. That obligation survives the end of their engagement.

5. Security (art. 32)

We implement appropriate technical and organisational measures, described in Annex C.

Two points are stated plainly because they are commonly overstated in this market:

1. Encryption at rest, stated precisely rather than as an unqualified claim (re-scoped 2026-08-13). Backup archives are encrypted at rest with AES-256. Storage volumes and the live tenant databases themselves are not separately encrypted at rest — see Annex C.1 for the full posture and what stands in its place.
2. Encryption at rest does not prevent us from reading tenant content, and we do not claim that it does. The Service must parse markdown server-side to build the wiki, resolve rules, and run search. A "zero-knowledge" architecture is not possible for this product and we will not describe it as one. What limits our access is the break-glass control in Annex C.4: opening your content through the Service only on a support ticket, logged, with you notified that it happened.

6. Subprocessors

1. You give general authorisation for us to engage subprocessors. The current list is published at Subprocessors list and maintained at hearthmoot.com/legal/subprocessors/.
2. We give at least 30 days' notice by email before adding or replacing a subprocessor. The notice goes to your account email address. There is nothing to subscribe to and no way to opt out of it: it is part of this agreement rather than a mailing list, so every account holder receives it.
3. You may object on reasonable data-protection grounds within those 30 days. We will work with you to find a resolution. If none is available, you may terminate the affected subscription without penalty and receive a pro-rata refund of the unused period, and the export window in section 11 runs from that date.
4. We impose on each subprocessor, by contract, data protection obligations no less protective than those in this DPA. We remain fully liable to you for a subprocessor's performance.
5. The subprocessors in place at the date of this DPA are listed in Annex B.

7. International transfers

Tenant data is stored in the EEA. Hosting is in Finland (Hetzner, Helsinki) and error reporting uses Sentry's EU region.

The business mailbox (Google Workspace) has no EU pinning, and it holds no tenant data: it receives email sent to the support and role addresses, and nothing else. A correspondent's own email is a separate processing activity, disclosed in Annex B.

One subprocessor can process tenant data outside the EEA. Our operator uses Anthropic's AI assistant, Claude, to run the Service. While it works on our servers, the data it reads, which can include tenant content, is processed by Anthropic in the United States. Nothing is stored there for us, and the transfer is covered by the EU Standard Contractual Clauses in Anthropic's data processing terms.

This is a design decision rather than a transfer-management exercise: it eliminates the international transfer question for tenant content instead of solving it with contractual mechanisms. If that ever changes, it is a subprocessor change under section 6 and gets the same notice and objection rights, and we would put an art. 46 transfer mechanism in place before any transfer occurred.

Paddle, as an independent controller for payment data, runs its own transfer arrangements. Those are Paddle's responsibility and are outside this DPA.

8. Assisting you with data subject rights

1. The Service gives you direct access to the personal data in your tenant. In most cases you can answer an access, rectification, erasure, or portability request yourself, immediately, without contacting us: the content is yours, in your tenant, and exportable at any time.
2. Where you cannot, we assist you by appropriate technical and organisational measures, taking into account the nature of the processing.
3. If a data subject contacts us directly about data in your tenant, we do not respond on the substance. We tell them to contact you and, where we can identify the tenant, we tell you.
4. Assistance under this section is provided at no charge for requests of ordinary volume.

9. Assisting you with arts. 32–36

We assist you, taking into account the nature of processing and the information available to us, with:

1. security of processing (art. 32) — see Annex C;
2. breach notification (arts. 33 and 34) — see section 10;
3. data protection impact assessments and prior consultation (arts. 35 and 36) — by providing the information in Annex A and Annex C on request.

10. Personal data breaches

1. We notify you without undue delay after becoming aware of a personal data breach affecting personal data we process on your behalf. Our internal target is 24 hours from confirmation, which exists to leave you time inside your own 72-hour clock.
2. Our notification includes, so far as we know it at the time: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide everything at once, we provide it in phases without further undue delay.
3. You decide whether the breach is notifiable to your supervisory authority under art. 33 and whether affected data subjects must be told under art. 34. That decision is the Controller's and we do not make it for you.
4. Where we are Controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it.
5. Our internal procedure is documented in a written breach procedure, written before launch rather than after an incident.

11. Deletion and return

1. At the end of the subscription we follow the published timetable, which is also in Subscription Terms §8:

Event	Timing
Tenant suspended	End of the paid period
Data retained, export available	30 days after suspension
Tenant deleted	60 days after suspension
Purged from backups	90 days after suspension

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination. Dunning has no fixed length and nothing is deleted while it runs.

1. Return is by self-service export: the complete markdown vault plus a database export, in the format the data went in. It is available throughout the retention window.
2. Deletion at 60 days is from live systems. Backups are on a rolling cycle and are purged by 90 days. Between those dates the data exists only in encrypted backups that are not accessible to the Service and are not restored on request. At day 90 the per-tenant backup key is destroyed (its escrow record is cleared), so an archive copy that outlives its storage is permanently unreadable — deletion by key destruction is part of the purge. This is the standard art. 28(3)(g) backup carve-out and we state the actual window rather than leaving it vague.
3. We delete rather than return by default at the end of the retention window, unless EU or Member State law requires storage. We do not keep copies for our own purposes.

12. Audit

1. We make available to you the information necessary to demonstrate compliance with art. 28, including this DPA, Subprocessors list, Annex C, and the art. 30(2) record.
2. You may audit no more than once per twelve months, on 30 days' written notice, unless a breach affecting your data or a supervisory authority's instruction gives cause for more.
3. Audits are documentary by default. We answer a reasonable written questionnaire and provide the documents above. On-site or hands-on technical audit of production infrastructure is not available, because tenants are co-located on shared hosts and physical or interactive access by one customer would compromise other customers' data. This is a real limit and we state it rather than promising an audit we could not permit. Where documentary evidence does not satisfy you, we will, on request, set up an inspection of a staging replica: a host provisioned from the same templates, compose files and hardening steps as production, carrying synthetic tenants, on the notice in item 2 and at our reasonable cost. No such host runs permanently; we build one for the inspection. A replica demonstrates the built posture rather than any live machine, and we say so rather than presenting it as more.
4. Where a supervisory authority requires an inspection we cannot satisfy documentarily, we cooperate with the authority directly.
5. You bear your own audit costs. We may charge our reasonable costs for audits beyond the annual one.

13. Liability and duration

1. Liability under this DPA is subject to the limitations in Subscription Terms §14, except where the GDPR (in particular art. 82) provides otherwise. Nothing here limits a data subject's rights against either party.
2. This DPA takes effect when you accept the Subscription Terms and continues until all personal data processed on your behalf has been deleted under section 11.
3. Sections 4, 10, 11, and 12 survive termination for as long as we hold any of your data.

---

Annex A — Details of processing (art. 28(3), art. 30(2))

Subject matter. Provision of the hosted Hearthmoot campaign platform.

Duration. For the term of the subscription, plus the retention window in section 11.

Nature and purpose. Storage, parsing, indexing, display, backup, and export of campaign content so that the Controller and the players it admits can use the Service. Processing is automated and instruction-driven. No profiling, no automated decision-making with legal or similarly significant effects, no advertising, no model training.

Categories of data subject.

Category	Notes
The Controller (the DM)	Also our own Controller-role data subject for account data
Players admitted to the tenant	Typically 1–6 people, usually the DM's friends

Categories of personal data.

Category	Examples	Source
Player identifiers	Display name chosen by the player or DM; tenant passcode	Entered in the tenant
Campaign content	Character sheets, session notes, wiki pages, messages, anything the DM or players write	Entered in the tenant
Technical data	IP address, browser user agent, timestamps in server and access logs	Generated by use
Error data	Stack traces and request context when the software fails	Generated on error

Special categories (art. 9). None are requested, required, or expected. The Service has no field for them. Free-text fields could in principle contain anything, which is inherent in a notes product; the Controller is responsible for what is entered.

Children's data. The Service is not directed at children and a subscription requires an adult (Subscription Terms §2.4). A DM may admit players under 16 as tenant participants. Where that happens the Controller is responsible for the lawful basis and any parental consent.

Deliberate minimisation. The Service does not collect player email addresses. Players join with a name and a passcode issued by the DM. This was a design choice retained on purpose and it should not be reversed without a fresh assessment.

---

Annex B — Subprocessors at the date of this DPA

Maintained in full, with purposes and locations, at Subprocessors list.

Subprocessor	Purpose	Location of processing
Hetzner Online GmbH	Hosting, compute, storage, backups	Finland (Helsinki)
Functional Software, Inc. (Sentry), EU region	Error reporting	EU region
Resend, Inc. (EU region)	Transactional email	EU region
Cloudflare, Inc.	DNS, CDN and reverse proxy	Global edge; EEA origin
Better Stack, Inc.	Uptime monitoring of our own public addresses, and the public status page	United States — no tenant content and no customer personal data; EU SCCs in their published DPA
Google Ireland Ltd — Google Workspace	Business mailbox for the support and role addresses (support@, privacy@, abuse@)	Global under Google's SCCs; no EU data-region pinning on the current plan
Anthropic, PBC	AI assistant (Claude) our operator uses for support email and for running the Service; reads what that work touches, which can include tenant content	United States, under the EU SCCs in Anthropic's data processing terms; nothing stored for us; no model training

Tenant content never reaches Google Workspace. It is the company's own mailbox: what it processes is the email of whoever writes to those addresses, which is why it is listed here at all. A customer's campaign, vault and characters are not in it.

Paddle is not a subprocessor. It is an independent controller for payment data.

---

Annex C — Technical and organisational measures (art. 32)

C.1 Encryption. TLS between the customer's browser and our servers. Traffic between our own servers travels over the hosting provider's private network and is not separately encrypted. Backup archives are encrypted at rest with AES-256. Storage volumes and the live tenant databases are not separately encrypted at rest — re-scoped by an explicit 2026-08-13 decision, not an oversight. What stands in its place: the hosting infrastructure (Hetzner) runs in data centres holding ISO 27001 certification for physical and infrastructure controls; tenant data is held EEA-only (Annex B); and access to the data underneath is bounded by C.3 and C.4 rather than by cryptography. This is a real gap against a stolen disk or a host-level compromise, stated as one rather than described as covered. It is revisited on either of two triggers: paid legal advice that the exposure is unacceptable for the risk, or the first complaint involving sensitive tenant content — whichever comes first.

C.2 Tenant isolation. One tenant is one campaign, with its own database and its own vault volume. Databases are never merged across tenants. Isolation of the tenant surface is reviewed before launch (PRODUCT.md Phase 5 gate 6) and covers authentication, session handling, the vault-path jail, database credentials, network, and volumes.

C.3 Access control. Named accounts, no shared administrative credentials, key-based SSH only, and least privilege. Secrets are not stored in images, repositories, or logs.

C.4 Break-glass access to tenant content. No routine browsing of tenant vaults. Opening tenant content through the Service happens only when a support ticket requires it, is recorded in an audit log, and the tenant is notified that it happened. This is the demonstrable control behind the no-monitoring commitment. Operators also log in to the hosts to run, repair and back up the Service; that maintenance access is not logged per tenant.

C.5 No content scanning. No cross-tenant indexing, no analytics on page bodies, no automated inspection, no model training on tenant content.

C.6 Backups. Scheduled per-tenant snapshots of the vault and database, held off the serving host, encrypted, with retention matching the published 90-day purge. Restore has been executed as a drill, not merely configured.

C.7 Availability and resilience. Uptime monitoring with alerting, a public status page, and documented restore procedures.

C.8 Logging. Server and access logs kept for security and troubleshooting, and not used to profile users. Retention is bounded by volume rather than by date. Every container in a tenant stack, and the shared front door that routes to it, writes through a log driver with a fixed size per file and a fixed number of files, so the oldest entries are deleted once that ceiling is reached. The tenant ceiling is set in the deployment file the provisioner copies into every tenant, so it holds for all of them without an operator step. How long a given entry survives therefore depends on the traffic that tenant carries, and no dated schedule is enforced on top of it. Logs written by the account-side systems are controller-role processing, outside this DPA, and are described in Privacy Policy (section 1).

C.9 Testing and review. Security review of the tenant-isolation surface before launch, and re-review after remediation. Measures are reviewed when the architecture changes.

---

Version: 1.1. Date: 2026-10-02.

This Data Processing Agreement ("DPA") forms part of the Hearthmoot Hosted Subscription Terms between you ("Controller") and Hearthmoot (eenmanszaak), Gijsbrecht van IJselsteinstraat 159, 1082 KH Amsterdam, the Netherlands ("Processor", "we"). It is accepted when you accept those terms and needs no separate signature.

Where this DPA conflicts with the Subscription Terms on the processing of personal data, this DPA prevails.

1. Roles

1. For campaign data in your tenant — your players' names, characters, session notes, and anything else you or your players enter — you are the Controller and we are the Processor.
2. For your account and billing data we are an independent Controller. That processing is outside this DPA and is described in Privacy Policy.
3. Paddle is an independent Controller for payment data. It is not our subprocessor and we do not direct its processing.
4. If your use of the Service is purely personal or household activity, the GDPR may not apply to you at all (art. 2(2)(c)). This DPA is written so that it works if it does apply. Running paid games, or a table that is not a private social circle, will usually take you outside the household exemption.

2. Subject matter and duration

We process personal data on your behalf only to provide the Service, for as long as your subscription runs, plus the retention window in section 11.

The subject matter, nature and purpose of the processing, the categories of data subject, and the categories of personal data are set out in Annex A.

3. Processing only on documented instructions

1. We process personal data only on your documented instructions, including on transfers to a third country. The Subscription Terms, this DPA, and your use of the Service's features are your documented instructions. No separate instruction form is needed for ordinary use.
2. We tell you if we believe an instruction infringes the GDPR or other EU or Member State data protection law. We may suspend the affected processing until the instruction is resolved.
3. If we are required by EU or Member State law to process beyond your instructions, we inform you of that requirement before processing, unless that law prohibits informing you on important grounds of public interest.
4. We do not process tenant content for any purpose of our own. No content scanning, no analytics on page bodies, no cross-tenant indexing, no model training. This is a commitment under Subscription Terms §9.3 and it applies here as an instruction limit.

4. Confidentiality

Every person we authorise to process personal data is bound by an obligation of confidentiality, whether by contract of employment, contractor agreement, or statutory duty. That obligation survives the end of their engagement.

5. Security (art. 32)

We implement appropriate technical and organisational measures, described in Annex C.

Two points are stated plainly because they are commonly overstated in this market:

1. Encryption at rest, stated precisely rather than as an unqualified claim (re-scoped 2026-08-13). Backup archives are encrypted at rest with AES-256. Storage volumes and the live tenant databases themselves are not separately encrypted at rest — see Annex C.1 for the full posture and what stands in its place.
2. Encryption at rest does not prevent us from reading tenant content, and we do not claim that it does. The Service must parse markdown server-side to build the wiki, resolve rules, and run search. A "zero-knowledge" architecture is not possible for this product and we will not describe it as one. What limits our access is the break-glass control in Annex C.4: access only on a support ticket, logged, with you notified that it happened.

6. Subprocessors

1. You give general authorisation for us to engage subprocessors. The current list is published at Subprocessors list and maintained at hearthmoot.com/subprocessors.
2. We give at least 30 days' notice by email before adding or replacing a subprocessor. The notice goes to your account email address. There is nothing to subscribe to and no way to opt out of it: it is part of this agreement rather than a mailing list, so every account holder receives it.
3. You may object on reasonable data-protection grounds within those 30 days. We will work with you to find a resolution. If none is available, you may terminate the affected subscription without penalty and receive a pro-rata refund of the unused period, and the export window in section 11 runs from that date.
4. We impose on each subprocessor, by contract, data protection obligations no less protective than those in this DPA. We remain fully liable to you for a subprocessor's performance.
5. The subprocessors in place at the date of this DPA are listed in Annex B.

7. International transfers

Tenant data stays in the EEA. Hosting is in Germany and Finland (Hetzner: Falkenstein, Helsinki) and error reporting uses Sentry's EU region.

The one subprocessor without EU pinning is the business mailbox (Google Workspace), and it holds no tenant data: it receives email sent to the support and role addresses, and nothing else. The claim above is about tenant CONTENT and is exact — a correspondent's own email is a separate processing activity, disclosed in Annex B rather than folded into this sentence.

This is a design decision rather than a transfer-management exercise: it eliminates the international transfer question for tenant content instead of solving it with contractual mechanisms. If that ever changes, it is a subprocessor change under section 6 and gets the same notice and objection rights, and we would put an art. 46 transfer mechanism in place before any transfer occurred.

Paddle, as an independent controller for payment data, runs its own transfer arrangements. Those are Paddle's responsibility and are outside this DPA.

8. Assisting you with data subject rights

1. The Service gives you direct access to the personal data in your tenant. In most cases you can answer an access, rectification, erasure, or portability request yourself, immediately, without contacting us: the content is yours, in your tenant, and exportable at any time.
2. Where you cannot, we assist you by appropriate technical and organisational measures, taking into account the nature of the processing.
3. If a data subject contacts us directly about data in your tenant, we do not respond on the substance. We tell them to contact you and, where we can identify the tenant, we tell you.
4. Assistance under this section is provided at no charge for requests of ordinary volume.

9. Assisting you with arts. 32–36

We assist you, taking into account the nature of processing and the information available to us, with:

1. security of processing (art. 32) — see Annex C;
2. breach notification (arts. 33 and 34) — see section 10;
3. data protection impact assessments and prior consultation (arts. 35 and 36) — by providing the information in Annex A and Annex C on request.

10. Personal data breaches

1. We notify you without undue delay after becoming aware of a personal data breach affecting personal data we process on your behalf. Our internal target is 24 hours from confirmation, which exists to leave you time inside your own 72-hour clock.
2. Our notification includes, so far as we know it at the time: the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact point. Where we cannot provide everything at once, we provide it in phases without further undue delay.
3. You decide whether the breach is notifiable to your supervisory authority under art. 33 and whether affected data subjects must be told under art. 34. That decision is the Controller's and we do not make it for you.
4. Where we are Controller (account and billing data), we notify the Autoriteit Persoonsgegevens within 72 hours where art. 33 requires it.
5. Our internal procedure is documented in a written breach procedure, written before launch rather than after an incident.

11. Deletion and return

1. At the end of the subscription we follow the published timetable, which is also in Subscription Terms §8:

Event	Timing
Tenant suspended	End of the paid period
Data retained, export available	30 days after suspension
Tenant deleted	60 days after suspension
Purged from backups	90 days after suspension

Where the suspension was for a failed payment and the subscription is afterwards terminated for non-payment, the three periods run from that termination. Dunning has no fixed length and nothing is deleted while it runs.

1. Return is by self-service export: the complete markdown vault plus a database export, in the format the data went in. It is available throughout the retention window.
2. Deletion at 60 days is from live systems. Backups are on a rolling cycle and are purged by 90 days. Between those dates the data exists only in encrypted backups that are not accessible to the Service and are not restored on request. At day 90 the per-tenant backup key is destroyed (its escrow record is cleared), so an archive copy that outlives its storage is permanently unreadable — deletion by key destruction is part of the purge. This is the standard art. 28(3)(g) backup carve-out and we state the actual window rather than leaving it vague.
3. We delete rather than return by default at the end of the retention window, unless EU or Member State law requires storage. We do not keep copies for our own purposes.

12. Audit

1. We make available to you the information necessary to demonstrate compliance with art. 28, including this DPA, Subprocessors list, Annex C, and the art. 30(2) record.
2. You may audit no more than once per twelve months, on 30 days' written notice, unless a breach affecting your data or a supervisory authority's instruction gives cause for more.
3. Audits are documentary by default. We answer a reasonable written questionnaire and provide the documents above. On-site or hands-on technical audit of production infrastructure is not available, because tenants are co-located on shared hosts and physical or interactive access by one customer would compromise other customers' data. This is a real limit and we state it rather than promising an audit we could not permit. Where documentary evidence does not satisfy you, we offer an inspection of a staging replica: a host provisioned from the same templates, compose files and hardening steps as production, carrying synthetic tenants, on the notice in item 2 and at our reasonable cost. A replica demonstrates the built posture rather than any live machine, and we say so rather than presenting it as more.
4. Where a supervisory authority requires an inspection we cannot satisfy documentarily, we cooperate with the authority directly.
5. You bear your own audit costs. We may charge our reasonable costs for audits beyond the annual one.

13. Liability and duration

1. Liability under this DPA is subject to the limitations in Subscription Terms §14, except where the GDPR (in particular art. 82) provides otherwise. Nothing here limits a data subject's rights against either party.
2. This DPA takes effect when you accept the Subscription Terms and continues until all personal data processed on your behalf has been deleted under section 11.
3. Sections 4, 10, 11, and 12 survive termination for as long as we hold any of your data.

---

Annex A — Details of processing (art. 28(3), art. 30(2))

Subject matter. Provision of the hosted Hearthmoot campaign platform.

Duration. For the term of the subscription, plus the retention window in section 11.

Nature and purpose. Storage, parsing, indexing, display, backup, and export of campaign content so that the Controller and the players it admits can use the Service. Processing is automated and instruction-driven. No profiling, no automated decision-making with legal or similarly significant effects, no advertising, no model training.

Categories of data subject.

Category	Notes
The Controller (the DM)	Also our own Controller-role data subject for account data
Players admitted to the tenant	Typically 1–6 people, usually the DM's friends

Categories of personal data.

Category	Examples	Source
Player identifiers	Display name chosen by the player or DM; tenant passcode	Entered in the tenant
Campaign content	Character sheets, session notes, wiki pages, messages, anything the DM or players write	Entered in the tenant
Technical data	IP address, browser user agent, timestamps in server and access logs	Generated by use
Error data	Stack traces and request context when the software fails	Generated on error

Special categories (art. 9). None are requested, required, or expected. The Service has no field for them. Free-text fields could in principle contain anything, which is inherent in a notes product; the Controller is responsible for what is entered.

Children's data. The Service is not directed at children and a subscription requires an adult (Subscription Terms §2.4). A DM may admit players under 16 as tenant participants. Where that happens the Controller is responsible for the lawful basis and any parental consent.

Deliberate minimisation. The Service does not collect player email addresses. Players join with a name and a passcode issued by the DM. This was a design choice retained on purpose and it should not be reversed without a fresh assessment.

---

Annex B — Subprocessors at the date of this DPA

Maintained in full, with purposes and locations, at Subprocessors list.

Subprocessor	Purpose	Location of processing
Hetzner Online GmbH	Hosting, compute, storage, backups	Germany (Falkenstein) / Finland (Helsinki)
Functional Software, Inc. (Sentry), EU region	Error reporting	EU region
Resend, Inc. (EU region)	Transactional email	EU region
Cloudflare, Inc.	DNS, CDN and reverse proxy	Global edge; EEA origin
Better Stack, Inc.	Uptime monitoring of our own public addresses, and the public status page	United States — no tenant content and no customer personal data; EU SCCs in their published DPA
Google Ireland Ltd — Google Workspace	Business mailbox for the support and role addresses (support@, privacy@, abuse@)	Global under Google's SCCs; no EU data-region pinning on the current plan

Tenant content never reaches Google Workspace. It is the company's own mailbox: what it processes is the email of whoever writes to those addresses, which is why it is listed here at all. A customer's campaign, vault and characters are not in it.

Paddle is not a subprocessor. It is an independent controller for payment data.

---

Annex C — Technical and organisational measures (art. 32)

C.1 Encryption. TLS for all data in transit. Backup archives are encrypted at rest with AES-256. Storage volumes and the live tenant databases are not separately encrypted at rest — re-scoped by an explicit 2026-08-13 decision, not an oversight. What stands in its place: the hosting infrastructure (Hetzner) runs in data centres holding ISO 27001 certification for physical and infrastructure controls; tenant data is held EEA-only (Annex B); and access to the data underneath is bounded by C.3 and C.4 rather than by cryptography. This is a real gap against a stolen disk or a host-level compromise, stated as one rather than described as covered. It is revisited on either of two triggers: paid legal advice that the exposure is unacceptable for the risk, or the first complaint involving sensitive tenant content — whichever comes first.

C.2 Tenant isolation. One tenant is one campaign, with its own database and its own vault volume. Databases are never merged across tenants. Isolation of the tenant surface is reviewed before launch (PRODUCT.md Phase 5 gate 6) and covers authentication, session handling, the vault-path jail, database credentials, network, and volumes.

C.3 Access control. Named accounts, no shared administrative credentials, key-based SSH only, and least privilege. Secrets are not stored in images, repositories, or logs.

C.4 Break-glass access to tenant content. No routine browsing of tenant vaults. Access happens only when a support ticket requires it, is recorded in an audit log, and the tenant is notified that it happened. This is the demonstrable control behind the no-monitoring commitment.

C.5 No content scanning. No cross-tenant indexing, no analytics on page bodies, no automated inspection, no model training on tenant content.

C.6 Backups. Scheduled per-tenant snapshots of the vault and database, held off the serving host, encrypted, with retention matching the published 90-day purge. Restore has been executed as a drill, not merely configured.

C.7 Availability and resilience. Uptime monitoring with alerting, a public status page, and documented restore procedures.

C.8 Logging. Server and access logs kept for security and troubleshooting, and not used to profile users. Retention is bounded by volume rather than by date. Every container in a tenant stack, and the shared front door that routes to it, writes through a log driver with a fixed size per file and a fixed number of files, so the oldest entries are deleted once that ceiling is reached. The tenant ceiling is set in the deployment file the provisioner copies into every tenant, so it holds for all of them without an operator step. How long a given entry survives therefore depends on the traffic that tenant carries, and no dated schedule is enforced on top of it. Logs written by the account-side systems are controller-role processing, outside this DPA, and are described in Privacy Policy (section 1).

C.9 Testing and review. Security review of the tenant-isolation surface before launch, and re-review after remediation. Measures are reviewed when the architecture changes.

---

Version: 1.0. Date: 2026-09-30.