Data Processing Agreement

Part of the Terms. This DPA is part of Mulno's Terms of Service (section 7) from the first time the customer uses Mulno. It needs no signature. This rider names the parties and settles what a click-through can:

• Controller: the customer under the Terms: the organisation the workspace's owner acts for or, if the owner is an individual who doesn't act for one, that person. It is identified by the legal name given when the workspace is created or by an owner or admin on its Billing page or, without one, by the workspace's name and its owner's e-mail address in Mulno. Paddle's invoice doesn't always carry the buyer's name, so it is not relied on.
• Processor: Somnolent Team Limited, 374/19 Soi Lat Phrao 71, Khlong Chao Khun Sing, Wang Thonglang, Bangkok 10310, Thailand, company registration no. 0105566229327.
• The Agreement is the Terms of Service in force, with any Enterprise agreement or order the customer has. Where this DPA and the Agreement conflict on data protection, this DPA wins; the Terms (section 1) set the full order.
• Effective from the date the customer first accepted the Terms, which is no later than its first use of Mulno. The Service records which version was accepted, by which account and when.
• Notices under this DPA go by e-mail to the workspace's owner (Terms section 18), including the notice of a new Sub-processor (§10.2).
• Region is the one the workspace chose when it was created (Annex 1 §5).
• Standard contractual clauses: Annex 4's choices are incorporated by reference where §14.2 applies, and the parties above are the exporter and the importer.
• A countersigned copy, with negotiated terms, is for Enterprise customers. It replaces this DPA for that customer. It fills the signature block at the end with the customer's legal name, address and registration number, and the date.

For a countersigned copy only: the Controller is [[STUDIO LEGAL NAME]], [[STUDIO ADDRESS]], [[STUDIO REGISTRATION NUMBER]], effective [[DATE]], and the Agreement is [[MAIN AGREEMENT / ORDER FORM REFERENCE]]. The two are each a "Party".

1. Definitions

1.1 "Data Protection Law" means, as each applies to a Party's processing: Regulation (EU) 2016/679 (the GDPR); the GDPR as it forms part of UK law with the Data Protection Act 2018 (the UK GDPR); Thailand's Personal Data Protection Act B.E. 2562 (2019) (the PDPA) and its subordinate regulations; the California Consumer Privacy Act as amended by the California Privacy Rights Act and its regulations (the CCPA), and other US state privacy laws; and any other law on personal data that applies to the Controller or the Processor.

1.2 "Personal Data", "Processing", "Data Subject", "Controller", "Processor", "Sub-processor" and "Personal Data Breach" have the meanings in the GDPR, and the corresponding terms of the PDPA ("data controller", "data processor", and so on) are read as the same.

1.3 "Service" means the Processor's hosted service for remote playtests (the "broker": invite codes, redemption, upload authorisation, NDA acceptance records, the Controller's privacy notice for testers and records of which version the Launcher showed, capture-health records, campaign administration, deletion requests), the platform service beside it (workspaces, projects, builds and their storage settings), and, only where Annex 1 §4 says so, storage the Processor provides for Recordings or a read key the Controller lends it.

1.4 "Software" means the Processor's software that runs on devices the Processor doesn't operate: the Unity package and capture library in the Controller's game, the uploader, the Mulno Launcher, Mulno Studio and the mulno command-line tool.

1.5 "Recordings" means what the Software records of a tester: gameplay video, game audio, microphone, webcam, voice notes, in-game events and positions, the session manifest (including the consent and NDA records), and anything derived from them (transcripts, notes).

2. Scope: what the Processor processes, and what it doesn't

2.1 The Service. The Processor processes Personal Data on the Controller's behalf only in the Service, as described in Annex 1.

2.2 The Software is not processing by the Processor. The Software runs on testers' and the Controller's own devices under the Controller's control, and sends Recordings to storage the Controller chooses. The Processor doesn't receive, access or control Recordings through the Software. The Controller is solely responsible for its processing with the Software, including its configuration (§7). The Processor warrants that the Software records only the streams a tester's consent record allows, and sends the Processor only what Annex 1 §2 lists (and, where it applies, what Annex 1 §4 lists).

2.3 Recordings in the Controller's own storage ("Private bucket", Annex 1 §4) are outside this DPA while the Controller lends the Processor no read key: the Processor never holds or reads them. Recordings in storage the Processor provides ("Mulno-hosted bucket" or "Mulno Cloud", Annex 1 §4) are within it, and so is everything the Processor reads or derives from Recordings under a lent read key (Annex 1 §4).

2.4 The Controller's own processors are outside this DPA: its storage provider (for a Private bucket), a speech-to-text provider it uses from Mulno Studio (such as OpenAI or ElevenLabs, under the Controller's own account and key), and an AI assistant it connects to mulno mcp. The Processor doesn't engage or instruct them, and they are not its Sub-processors.

2.5 What the Processor keeps for itself. The traffic log in Annex 1 §2, which Thai law asks the Processor to keep, and the statistics in §4.3 are the Processor's own processing as a controller, not processing for the Controller.

3. Subject matter and duration

The subject matter is the Service. The Processor processes Personal Data for the term of the Agreement and afterwards only as §16 allows.

4. Nature and purpose of processing

4.1 Checking testers' invite codes and the campaign's limits; issuing short-lived, single-object upload authorisations to the Controller's storage; recording upload progress; receiving and summarising capture-health records for the Controller; passing testers' deletion requests to the Controller and deleting a session's records on its instruction; limiting abuse; keeping an audit log of account actions; and, where Annex 1 §4 says so, storing Recordings for the Controller.

4.2 The Processor doesn't process the Personal Data for its own purposes, except as §2.5 and §4.3 allow.

4.3 Aggregate statistics. The Controller authorises the Processor to combine capture-health records (Annex 1 §2, only the fields of mulno.capture-health/v1) with those of its other customers into statistics about recorder, encoder, graphics hardware and upload performance, to find and fix faults in the Software. The statistics must not contain session IDs, campaign IDs or anything else that relates to a Data Subject or to the Controller, and they end the records' link to any person. That purpose is the Processor's own, so for combining the records into statistics the Processor is an independent controller (GDPR Art. 28(10)), not the Controller's processor: it relies on its own legitimate interest (GDPR Art. 6(1)(f); PDPA s.24(5)), publishes its own statement of that processing, and leaves out the record of any Data Subject who objects. The Controller discloses the records to it for that purpose, tells its testers so (the notice template's §6 does), and may turn capture-health off.

5. Data Subjects and Personal Data

Testers of the Controller's games, and anyone else a Recording captures, such as other players or people near a tester's webcam or microphone; and the types of Personal Data in Annex 1 §2 (and, for a Mulno-hosted bucket, Mulno Cloud or a lent read key, Annex 1 §4). The Controller's staff who use the Service are the Controller's own contacts with the Processor; the Processor handles their details as a controller under its own privacy notice, not under this DPA.

6. Instructions

6.1 The Processor processes Personal Data only on the Controller's documented instructions, including as to transfers to third countries (§14), unless the law it is subject to requires otherwise, in which case it tells the Controller before processing unless that law forbids it.

6.2 The Controller's instructions are this DPA, the Agreement, and the Controller's use of the Service: its campaigns' settings (limits, expiry, minimum age, capture-health on or off, the kill switch), its storage destination and the storage mode it chooses for each project (and any change to it), whether it lends a read key, its codes and their revocation, the sessions it deletes, and its requests under §11.

6.3 The Processor tells the Controller immediately if, in its opinion, an instruction infringes Data Protection Law.

7. The Controller's responsibilities

The Controller:

• (a) has a lawful basis for its processing and gives testers a notice that meets Data Protection Law (the Processor provides a template in the web app and on request), in a language they understand;
• (b) runs outside playtests with the consent screen (Consent Mode Screen), or Config only where it collected each tester's consent on paper first, never Off; keeps the recording indicator on (Show Recording Indicator; a remote build can't turn it off); sets a minimum age right for its testers' countries (20 for testers in Thailand unless a guardian consents; never below 13); and turns on "parental consent collected by studio" only when it has collected it;
• (c) keeps every version of its consent text and NDA text, byte for byte, with the build that showed it, and every version of the privacy notice it saves for the Launcher, so the versions and hashes in consent, NDA and notice records can be checked;
• (d) puts no names, e-mail addresses or other Personal Data into the Service's labels and free-text fields: campaign names, code tags, kill reasons and token labels (the contact details it publishes in its privacy notice or NDA, which the Launcher shows testers, are the exception: it chooses to publish those);
• (e) handles testers' requests and withdrawals, including deleting from its own storage what a withdrawn tester had already uploaded;
• (f) secures its own storage and credentials (the bucket setup the Service verifies, and on R2 the acknowledgement it gives), and its own processors (§2.4);
• (g) carries out any data protection impact assessment its processing needs (webcam or microphone recording, or testers under 18, are likely to need one), and revisits it before moving a project to Mulno Cloud or lending a read key;
• (h) for testers in the EU or UK, collects the consent the ePrivacy Directive Art. 5(3) and UK PECR reg. 6 require before anything is read from a tester's device (the notice template's §3 box), and doesn't use Decline Records Events for them;
• (i) sets an expiry on each campaign, or closes it when the playtest ends, so the retention in Annex 1 §2 starts;
• (j) gives instructions about a session or a tester (a deletion, a session ID, a tester's request) through the Service, not by e-mail. The Processor's mailbox is not used to process Personal Data for the Controller: if such Personal Data reaches it anyway, the Processor acts on it through the Service and deletes the message within 7 days.

8. Confidentiality

The Processor ensures that everyone it authorises to process the Personal Data is bound by confidentiality, by contract or by law, and processes it only as this DPA allows.

9. Security

9.1 The Processor implements the technical and organisational measures in Annex 3 (GDPR Art. 32; PDPA s.37(1), s.40), and reviews them at least once a year and after any significant change to the Service.

9.2 The Processor has chosen those measures for the risk of the processing, taking into account that, in Private-bucket mode, the Service holds no Recording and no direct identifier of a tester (Annex 1 §2). Where the Processor holds Recordings (a Mulno-hosted bucket or Mulno Cloud) or reads them (a lent read key), Annex 3's hosted-storage measures apply as well, and the Processor reviews them before it first holds or reads a Recording and after any change to how it does.

10. Sub-processors

10.1 The Controller gives general written authorisation for the Sub-processors in Annex 2.

10.2 The Processor gives the Controller at least 30 days' notice, by e-mail to the workspace's owner, before adding or replacing a Sub-processor. The Controller may object on reasonable data protection grounds within that period; if the Parties can't resolve the objection, the Controller may terminate the affected part of the Service without penalty and receive a refund of prepaid fees for it.

10.3 The Processor imposes on each Sub-processor, by contract, data protection obligations giving at least the protection of this DPA, and remains liable to the Controller for its Sub-processors as for itself.

11. Data Subjects' requests

11.1 The Processor passes to the Controller, without undue delay, any request it receives from a Data Subject about the Controller's data, and doesn't answer it except on the Controller's instruction. A tester's request made on the Processor's deletion page shows on that session in the Controller's campaign. A session ID is not a secret (it is on every moment link), so the page can't tell the tester's request from anyone else's, and the Processor doesn't delete on it at once. Where the Recording is in Mulno Cloud (or the Processor indexed it under a lent read key), the Service hides the session from everyone at once, so nobody in the Controller's workspace can open, search or export it unless an owner or admin restores it first (the restore is audited), tells the Controller's owners by e-mail and in the campaign, and deletes the Processor's copy for good 30 days after the request, unless an owner or admin restores it first. A plan change's hold (Annex 1 §4) does not delay that deletion. The Controller should restore it only if it is sure the request was not the Data Subject's own, or the law lets it keep the Recording (GDPR Art. 17(3)), and should then tell the Data Subject. A Data Subject's own request is an erasure request (the template tester notice grounds the Recording on the Controller's legitimate interests, so it is not a withdrawal of consent) that the Controller must honour unless the law lets it keep the Recording. If a Data Subject asks again after the Controller restored the session, the Service does not hide it again, so that repeating a request cannot keep a Recording hidden: it records the repeat in the Controller's audit log, e-mails each owner once (at most one such e-mail per session in 7 days) and lists the request again in the campaign with Delete now and Keep. Keep closes the request and is audited; Delete now is the Controller's instruction to delete at once (§11.2(b)). The Controller can also delete it right away, at any time (§11.2). Where the Recording is in the Controller's own storage and the Processor holds nothing of the session, the Processor only passes the request on and the Controller decides.

11.2 The Processor helps the Controller answer requests (access, rectification, erasure, restriction, portability, objection) by appropriate technical and organisational measures. Most are self-service in the Service and take effect at once; the 10 business days below apply only to what the Processor does on a request:

• (a) The Service's records of a session (Annex 1 §2, keyed by session ID, the only records in Private-bucket mode): the Controller deletes them itself, at once, from the session's campaign. On its request through the Service the Processor provides them within 10 business days. After a Data Subject's request (§11.1) for a session of a project the Service holds, the Processor deletes its records of it when its copy is deleted for good, 30 days after the request, unless the Controller restored the session.
• (b) A session in Mulno Cloud (Annex 1 §4): the Controller downloads its files through the Service whenever it wants until they are deleted for good (not while a Data Subject's request hides the session, §11.1: an owner or admin restores it first). An owner or admin deletes it in the Service in one of two ways, and the choice is the Controller's instruction (§6.2): right away (the Recording, its notes and its index rows are deleted at once and can't be restored), or with 30 days to undo (at once it is hidden from everyone, its index rows are deleted and it is kept only in storage; its Recording and notes are deleted for good 30 days later, or when a plan change's 30-day hold (Annex 1 §4) ends if that is later, unless the Controller restores it first). A session a Data Subject asked to have deleted on the Processor's deletion page (§11.1) is hidden at once and deleted for good 30 days after the request, unless the Controller restores it first (a plan change's hold does not delay it); the Controller can still delete it right away from its campaign. A repeat request after a restore is recorded and the owners are told, and nothing is hidden again (§11.1).
• (c) What the Processor derived under a lent read key (Annex 1 §4): the Controller deletes a session's derived data through the Service (its API today), at once, or turns the key off, which deletes everything derived for the project. The Recording itself is in the Controller's own bucket, for the Controller to delete. After a Data Subject's request (§11.1) the derived data of that session is hidden at once and deleted for good 30 days after the request, unless the Controller restores it first.
• (d) Anything else the Processor holds about a session for the Controller: provided or deleted within 10 business days of the Controller's request through the Service.

Database rows deleted under this clause leave the point-in-time backups within 30 days more (§16.1).

12. Assistance

Taking into account the nature of the processing and the information available to it, the Processor helps the Controller meet its obligations on security, Personal Data Breaches, data protection impact assessments and prior consultation with a supervisory authority (GDPR Arts 32–36; UK GDPR; PDPA s.37), including by providing the information in Annexes 1–3 and answering reasonable questions about the Service and the Software.

13. Personal Data Breaches

13.1 The Processor notifies the Controller without undue delay, and in any event within 48 hours, after becoming aware of a Personal Data Breach affecting Personal Data it processes for the Controller, so the Controller can still meet its own 72-hour deadline to authorities (GDPR Art. 33(1), PDPA s.37(4)).

13.2 The notice describes, as far as then known: the nature of the breach, the categories and approximate numbers of Data Subjects and records concerned, the likely consequences, the measures taken or proposed, and a contact for more information; the Processor sends what isn't yet known as soon as it is.

13.3 The Processor takes reasonable steps to contain the breach and helps the Controller notify authorities and Data Subjects. The Controller decides whether and how to notify them. Notice under this clause is not an admission of fault.

14. International transfers

14.1 The Processor is established in Thailand. The Service runs on Cloudflare's global network: requests are handled at the Cloudflare location nearest the tester, and the database is kept where Annex 1 §5 says.

14.2 Where the Controller's transfer of Personal Data to the Processor is a restricted transfer under the GDPR or UK GDPR — including where the Controller is outside the EEA but subject to the GDPR under Art. 3(2), and where both Parties are in Thailand — the Parties' EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914) are incorporated as Annex 4: Module Two (controller to processor) for the processing this DPA covers, and Module One (controller to controller) for the capture-health records the Processor uses for its own statistics (§4.3); for UK data, with the UK International Data Transfer Addendum. Where the Processor is itself subject to the GDPR under Art. 3(2), which those clauses don't address, the Parties use them until the European Commission adopts clauses for that case, and then put those in place. Where Thai Personal Data leaves Thailand for a country the PDPC hasn't recognised as adequate, the Parties rely on the appropriate safeguards recognised under PDPA s.29 and the PDPC's notification on transfers under s.29 (in force March 2024), namely standard contractual clauses.

14.3 The Processor's onward transfer to Cloudflare, Inc. (USA) relies on Cloudflare's customer data processing addendum, which incorporates the EU standard contractual clauses (Module Three where, as here, Cloudflare's customer acts as a processor) with the UK Addendum, and on Cloudflare's certification under the EU-US Data Privacy Framework and its UK Extension; for Thai Personal Data, on the same clauses as the PDPA s.29 safeguard.

15. Records and audits

15.1 The Processor keeps a record of its processing for the Controller (GDPR Art. 30(2), PDPA s.40(3)) and makes it available to a supervisory authority on request (GDPR Art. 30(4)).

15.2 On request, the Processor makes available the information needed to demonstrate compliance with this DPA: this DPA's annexes kept up to date, its what we store page and the database description behind it (which a test holds to the database schema), and the results of its security reviews.

15.3 Where that isn't enough, the Controller (or an independent auditor bound by confidentiality) may audit the Processor's compliance, including by inspection, at most once a year on 30 days' notice, and in addition where there are indications of non-compliance, after a Personal Data Breach, or where a supervisory authority requires it (on the notice the circumstances allow), during business hours, at the Controller's cost unless the audit finds a material breach, and without access to other customers' data.

16. Deletion and return

16.1 On termination of the Agreement, or earlier on the Controller's request for a campaign or the whole account, the Processor deletes the Personal Data it processes for the Controller within 30 days, unless the law requires it to keep it, and confirms in writing. Closing the workspace in the Service is such a request: access to it ends at once, and the deletion starts on the 14th day and ends within the 30. Before it deletes, the Controller may instead ask for the data to be returned: the Processor then gives it a copy of the Service's records for its campaigns in a machine-readable form, and its Recordings as §16.3 says, and deletes the rest. Because closing ends access at once, the Controller asks before it closes the workspace. Two audit logs are kept after the deletion, as the record of what was done with the data, and hold no direct identifier of a Data Subject: the broker's (Annex 1 §2), whose entries name no person and are deleted when each is a year old; and the workspace's own, from which the deletion removes every member's e-mail address, account id and IP-address hash, so that what is left (the action, its time and outcome, and the id of what it touched, which can be a session ID) stays until each entry is a year old and is deleted within 30 days after that. Deleted data leaves the database's point-in-time backups (Cloudflare D1 Time Travel, which can't be turned off) within 30 days more, and the Service's logs within 7 days.

16.2 In Private-bucket mode nothing else needs returning: the Processor never held the Recordings. Where a lent read key was in use, §16.1's 30 days covers what the Processor derived from them (its index, frames, cached transcripts), which is deleted rather than returned because the Controller holds the Recordings it came from; the Recordings themselves stayed in the Controller's own bucket throughout.

16.3 For Mulno-hosted storage (Annex 1 §4), before deleting, the Processor makes the Recordings available for the Controller to download for 30 days if the Controller asks before termination.

17. Liability

17.1 Each Party's total liability arising out of or in connection with this DPA, whatever the cause of action, is limited to the greater of (a) the fees paid for the Service under the Agreement in the 12 months before the event giving rise to the claim, and (b) US$100. This is one cap for the Agreement and this DPA together, not two: the two are never added up (Terms section 15). The Controller's duty to pay the fees, and its duty under the Agreement to cover the Processor for a claim by one of its testers, are not counted against it. The same limit applies in both storage modes (Annex 1 §4).

17.2 Nothing in this DPA limits a liability that the applicable law doesn't allow to be limited, including for fraud or wilful misconduct, or either Party's liability to Data Subjects or supervisory authorities under Data Protection Law (GDPR Art. 82 and 83; PDPA s.77–90).

18. Representatives

The Processor is established in Thailand and has not named an EU or UK representative (GDPR and UK GDPR Art. 27) yet. It names both before it opens accounts to people in the EEA or the UK. Until then, the Controller doesn't recruit testers there (Terms section 8), and the Service refuses a campaign whose audience is Europe or Worldwide. If the Processor learns that it holds Personal Data of testers in the EEA or the UK, it tells the Controller, which closes the campaign. The Processor is established in Thailand, so PDPA s.37(5) asks it for no representative there.

19. Governing law and jurisdiction

This DPA is governed by the laws of Thailand, and the courts of Bangkok, Thailand, have exclusive jurisdiction, without prejudice to Data Protection Law that applies regardless of that choice, and to the governing law and forum the standard contractual clauses in Annex 4 require.

20. Term

This DPA lasts as long as the Processor processes Personal Data for the Controller, and §16 survives it.

21. US state privacy laws

Where the CCPA or another US state privacy law applies to the Personal Data, the Processor acts as the Controller's service provider (or processor, as that law says) and:

• (a) doesn't sell or share the Personal Data, as those laws define selling and sharing;
• (b) doesn't retain, use or disclose it for any purpose other than the business purposes in §4, or outside its direct business relationship with the Controller, except as those laws allow (§4.3's statistics are one such use);
• (c) doesn't combine it with personal information it receives from anyone else or collects itself, except as those laws allow;
• (d) complies with those laws and gives the Personal Data the level of privacy protection they require;
• (e) tells the Controller if it decides it can no longer meet these duties; and
• (f) lets the Controller take reasonable and appropriate steps to stop and remedy any use of the Personal Data these duties don't allow, including by asking the Processor to delete it.

Countersigned copy only. Signed for [[STUDIO LEGAL NAME]]: ____________________ Name: __________ Date: __________

Signed for Somnolent Team Limited: ____________________ Name: __________ Date: __________

Annex 1: Processing details

1. How the Software runs, and where the Service comes in

• Local playtests (no invite code): the Software records on the tester's or the Controller's computer, and the Controller collects the files. The Service isn't involved and receives nothing.
• Remote playtests (an invite code): the Software redeems the code at the Service, then uploads the Recordings from the tester's computer straight to the storage in §4, using upload authorisations the Service signs. After the upload the Software sends the Service one capture-health record, unless the Controller turned them off.

2. What the Service keeps (remote playtests)

The same in every storage mode.

Deleted rows remain in the database's point-in-time backups for up to 30 days (§16.1). Cloudflare, as Sub-processor, sees each connection's metadata (IP address, approximate location, TLS details) while handling it; that is not copied into the records above.

Labels and free-text fields (campaign names, code tags, kill reasons) can hold whatever the Controller types; §7(d) keeps Personal Data out of them.

3. Data Subjects

Testers of the Controller's games, and anyone else a Recording captures (other players, people near a tester's webcam or microphone). Testers may include people under 18 (the Software records only events of a tester under the Controller's minimum age, unless the Controller collected parental consent).

4. Storage mode

The Controller chooses a storage mode for each project in the Service, and may change it; each choice and change is a documented instruction (§6.2), recorded in the Controller's audit log. This DPA covers every mode below without a new signature. Only the modes the Controller actually uses apply to it.

• Private bucket. Recordings go to the Controller's own Cloudflare R2 bucket (Amazon S3 isn't offered in the beta). The Processor never receives them. Apart from the setup check — which writes a small probe object under the campaign's upload prefix and tries to overwrite, read and list it, to prove the key can't, and discards any answer unread — it makes no request to that bucket itself. R2 has no write-only key: the key the Controller gives the Service, which the Service keeps encrypted and uses only to sign upload authorisations (testers never receive it), can list and read the whole bucket. The Controller acknowledged this in the Service before the campaign took an upload. A campaign uses its own bucket or, once its project names one, its project's bucket (shared by that project's campaigns), with a lock rule on incoming/ either way.
• Mulno-hosted bucket (offered by hand to beta studios). Recordings go to an R2 bucket in the Processor's Cloudflare account, in the region the Parties agree in writing when it is set up. The Processor holds the Recordings as the Controller's processor: Annex 3's hosted-storage measures, §16.3 and a Recordings row in Annex 2 apply. Reviewers get read access in the way the Parties agree in writing when it is set up.
• Mulno Cloud. Recordings go to the Processor's own Cloudflare R2, one sessions bucket and one builds bucket per region, shared by every Mulno Cloud project in that region and kept apart by object key, never shared with a Private project's own bucket. The Processor holds the Recordings as the Controller's processor for the whole of the project — Annex 3's hosted-storage measures and §16.3 apply. Signed-in members get short-lived signed reads; nothing is public. A session is kept for the retention of the workspace's plan, then hidden and deleted 30 days later; when a plan change shortens that retention, nothing is deleted for 30 days and the workspace's owners are told by e-mail (Terms section 12). The Controller can also delete one session at any time (§11.2).
• A lent read key on a Private project. The Controller's own bucket stays the Recordings' only home, but the Controller has given the Processor a read-only key and acknowledged this statement (stored with who and when, and cleared by a bucket change): "Mulno's servers will read this project's sessions — video, audio, events, notes and transcripts — to index them, show them in the browser and answer AI questions. The files stay in your bucket." The Processor then processes what it reads and derives (an index, frames, remote MCP answers, and — only if the Controller separately allows — hosted AI over frames) the same as for Mulno Cloud storage above, while the Recordings themselves never leave the Controller's bucket. Turning the key off ends this and the Processor deletes what it derived. This mode and Private-bucket mode above are not mutually exclusive over time: a project may run in either, and this Annex covers both without a new signature, because neither changes what the Processor does with a Recording it is not given — only whether it is given one.

5. Region

The Controller's workspace region is the one it chose when the workspace was created: APAC, EU or US: its own rows, and its Mulno Cloud buckets, are kept there — under Cloudflare's EU jurisdiction (a guarantee) for the EU, and by a location hint (Cloudflare's best effort, not a guarantee) for APAC and the US. The broker's records in §2 are an exception, whatever the workspace's region: until the broker becomes regional, they are kept in one Cloudflare D1 database with an Asia-Pacific (Singapore) location hint, together with the campaign's name and the workspace's own id — never its name. An EU-region Controller cannot create a campaign at all today: the Processor refuses the request outright, so no EU workspace's campaign metadata reaches this database until the broker itself becomes regional. The Workers run on Cloudflare's global network. The Controller's own storage is wherever the Controller put it.

Annex 2: Sub-processors

Not Sub-processors (§2.4): the Controller's storage provider (Private-bucket mode), a speech-to-text provider the Controller's own reviewers use from their own account, and an AI assistant a reviewer connects over MCP under their own account. Nor is Paddle, which bills the Controller as merchant of record: it sees only the Controller's own billing contact, which the Processor handles as a controller (§5), never a Data Subject's data. Nor is the provider of the Processor's mailbox (Google), which the Processor uses only for its own correspondence as a controller; §7(j) keeps the Personal Data it processes for the Controller out of it. See subprocessors.md for why these are listed there for transparency without being Sub-processors here. The Processor runs no AI of its own on Personal Data as of this DPA's date; hosted AI would be added to this list under §10 before use, named, with the terms ai-statement.md states.

Annex 3: Technical and organisational measures

Data minimisation by design

• In Private-bucket mode the Service never receives Recordings: uploads go from the tester's computer to the Controller's storage with authorisations the Service signs, and the Service has no code that reads or lists an object.
• No tester name, e-mail or birth date is stored, and no IP address except in the traffic log (Annex 1 §2), which holds no ID that could join it to a session. The database is described column by column, with retention, and a test fails if the schema and that description differ.

Access and authentication

• Invite codes (80 bits), upload tickets (256 bits) and API tokens are stored only as SHA-256 hashes; a copy of the database can't be replayed as a working code, ticket or token.
• Every broker route except the health check, the deletion-request form (which flags the session and, for one in Mulno Cloud, hides it at once and has it deleted 30 days later unless the Controller restores it; it never deletes at once, and it answers the same whether or not the session exists) and two unbuilt stubs that answer 501 requires a studio token, an invite code, an upload ticket or the platform service's own secret; every studio query is scoped to the token's studio; one studio's token can't reach another's campaigns (tested). Every platform-service route that reads or changes a workspace's data needs a signed-in member of that workspace, a workspace invitation's one-time token, or a key shared only between the Processor's own services; the only open ones are sign-in itself, the public keys that verify entitlement tokens, Paddle's signed webhook, the page Paddle's checkout opens on, a moment link's public preview (which shows nothing of the game) and the health check.
• Requests are rate-limited per credential and per network address; the Controller can kill a campaign, which stops new redemptions and uploads in progress at once.
• Access to the Processor's Cloudflare account is limited to named people (the owner today). Every account that can reach production (Cloudflare, the mailbox that receives its password resets, Paddle, the source repository and the domain registrar) uses multi-factor sign-in. The owner's computer locks its screen when left idle.
• A production change is made by the owner, or by an AI agent only after the owner's explicit confirmation of that specific change. AI agents deploy and migrate; they don't read Personal Data in production databases or logs, or in the Processor's mailbox.
• Sign-in to the platform service is by a single-use link (256 bits, stored only as a hash, valid about 15 minutes). A session is a __Host- cookie marked Secure, HttpOnly and SameSite=Lax, with a 256-bit secret kept only as a SHA-256 hash, and sign-out revokes it on the server.
• Every platform-service request is checked against the caller's live role in the workspace (owner, admin, member), so removing a member ends their access on their next request; the last owner can't be removed. The service sends no cross-origin (CORS) permissions, and a request that changes anything and has a body must be JSON. Another workspace's ids answer "not found", which tests check on every workspace-scoped route.
• Paddle's billing webhook is accepted only with a valid signature (an HMAC compared in constant time, within five minutes) and each event is applied once. The Processor never sees a card number.

Uploads

• Each authorisation is signed for one object, one method, one size and one hour, and only under the campaign's incoming/<campaign>/ prefix; the storage must refuse overwriting, which the Service verifies before a campaign takes its first upload.

Encryption

• All traffic to and from the Service uses TLS. The Controller's bucket credentials are encrypted with AES-256-GCM under a key held as a Worker secret, not in the database, and bound to their campaign; the broker's key rotates without downtime. A lent read key is sealed the same way inside a separate Worker that has no public address and is reachable only from the Service. The platform service's key for a Private project's bucket credentials and the lent-key key don't yet rotate without downtime. Cloudflare encrypts what D1 and R2 hold at rest (its own measure, Annex 2). Campaign configuration is encrypted before it reaches the Service with a key the Service doesn't hold.

Input and logging

• Every database statement is parameterised; input is size-capped and validated before processing; the broker's routes are also tested with randomised (fuzz) input.
• Logs carry fixed, non-sensitive fields (never a code, ticket, token, credential, body or raw path); Cloudflare's per-request "invocation logs" are turned off. Logs are kept 7 days.
• The web app and the platform service's own pages are served with a Content-Security-Policy (no inline script; they can't be framed) and HSTS. The Service checks a Private bucket only at Cloudflare R2 and Amazon S3 addresses, over https, and refuses redirects.
• An append-only audit log records account-level actions.

Retention and backups

• Capture-health records are deleted after 90 days by a scheduled job, and traffic-log rows after 90 days; rate-limit rows after an hour; the other records on the schedule Annex 1 §2 sets. Database backups (point-in-time restore) expire after 30 days.

Assurance

• As of this DPA's date, every security review of the Service (the broker, the platform service, the signer, remote MCP's authorisation) is done by the Processor's own AI review agent at its highest reasoning effort, not an outside firm; each review's findings are fixed and re-checked before what they gate ships. A security self-assessment organised by the domains of the CSA's Cloud Controls Matrix is kept current and published at caiq-lite.md; it is not the CSA's own CAIQ-Lite questionnaire or a STAR entry. No outside penetration test and no certification (SOC 2, ISO 27001) has been completed; the Processor starts toward one only once a paying customer's own review requires it.
• A Personal Data Breach reaches the Controller within 48 hours of the Processor becoming aware of it (§13).

Hosted storage (Mulno-hosted bucket, Mulno Cloud, or a lent read key)

• The bucket is private. A Mulno-hosted bucket serves one Controller; Mulno Cloud keeps every project of a region in that region's buckets, apart by object key, and signs each read or write for one object of one project, for a member of that project. A sessions bucket is separate from any builds bucket (a builds key needs read access a sessions key must not have). A write to it cannot overwrite an existing Recording (a conditional write, and on R2 a lock rule the guided setup requires before the first upload). Signed-in members read through short-lived signed URLs; the Processor's staff don't open a Recording except on the Controller's documented instruction, and every read the Processor's own servers make of a Recording under a lent read key is written to the Controller's own audit log. Reads the Processor's servers make of Recordings in Mulno Cloud (to index them, or to answer the Controller's members) aren't logged one by one. Access by the Processor's people outside the Service, such as through Cloudflare's dashboard, isn't in that log. One session is deleted as §11.2 says, and everything as §16 says.

Annex 4: Standard contractual clauses

The EU standard contractual clauses (Commission Implementing Decision (EU) 2021/914), in the Commission's own text, unchanged, are incorporated by reference where §14.2 applies, with these choices. The Processor gives a completed copy on request:

• Parties (Annex I.A): the parties named in the rider at the top: the Controller as data exporter (even when it is outside the EEA and subject to the GDPR under Art. 3(2), recital 7 of the Decision), the Processor as data importer.
• Description (Annex I.B): Annex 1 of this DPA; transfers are continuous for the Agreement's term; retention as Annex 1 §2 and §16. Sensitive data: none is intended. Webcam video and microphone audio may show it incidentally (for example a tester's health or religion from their appearance); the Processor draws no inference from it and applies Annex 3's hosted-storage measures to it.
• Competent supervisory authority (Annex I.C, Clause 13): the Controller's lead authority in the EU; for a Controller outside the EEA, the authority of the Member State where its Art. 27 representative is established or, where it needs none (Art. 27(2)), the authority of the Member State where the Data Subjects whose Personal Data is transferred are.
• Measures (Annex II): Annex 3 of this DPA. Sub-processors (Annex III): Annex 2.
• Options: Clause 7 (docking) included; Clause 9(a) Option 2 (general authorisation) with the 30 days' notice of §10.2; Clause 11(a)'s optional independent-redress wording left out. Clause 17: for Module Two, Option 2 (the law of the Member State where the Controller is established, or the law of Ireland where that law allows no third-party beneficiary rights or the Controller is outside the EEA); for Module One, the law of Ireland. Clause 18(b): the courts of the Member State whose law applies under Clause 17. The clauses need a Member State's law; §19's Thai choice doesn't apply to them.
• UK data: the UK International Data Transfer Addendum (version B1.0), Table 1–3 from the above, Table 4: neither party may end it.
• A Processor itself subject to the GDPR (Art. 3(2)) is outside what the 2021 clauses were made for (Art. 1 and recital 7 of the Decision); the Parties use them until the Commission adopts clauses for that case (§14.2).

Changes (2026-10-07)

• §1.4: the Mulno Launcher, which shows testers the privacy notice and the NDA, is named in the definition of "Software".
• §1.3, §7(a), §7(c), §7(d): the Controller's privacy notice for testers can be saved on a campaign for the Launcher to show before the build downloads; the Processor gives a template in the web app and on request; the Controller keeps every version it saves; contact details it publishes in the notice or an NDA are allowed there.
• Annex 1 §2: a new row for which version of the notice the Launcher showed a tester (version, SHA-256 and time against the session, kept as long as redemptions, never the text or a name); the campaign-settings row holds the notice's current text; the audit log names a notice set or shown.

Changes (2026-10-04)

• Rider: the legal name can be given when the workspace is created.
• §11.1 and §11.2: what is self-service and takes effect at once (a session's records; a Mulno Cloud session deleted right away or with 30 days to undo; a lent key's derived data) and what the Processor does within 10 business days. A Data Subject's request on the deletion page hides the session at once and deletes it for good 30 days after the request, unless the Controller restores it first (PLAN D164); a repeat request after a restore is recorded, mailed to the owners once and listed again with Delete now and Keep, and hides nothing (PLAN D165).
• §16.1: closing the workspace in the Service is a deletion request (from day 14, within 30 days); ask for a copy before closing; the two audit logs are kept until each entry's year ends, the workspace's own without its members' addresses, account ids and IP-address hashes.
• §18: the Service refuses Europe and Worldwide audiences.
• Annex 1 §2: campaign settings go when the workspace is closed; the audit log's year runs on after it.
• Annex 1 §4 and Annex 2: a Mulno Cloud session's retention, the 30-day hold and deleting one session; Email Service also sends the plan-change notice.