Data processing addendum

Last updated 2026-11-03

This data processing addendum (“DPA”) applies when an organization uses the Freero service at https://freero.app/ and, in doing so, has Kaiten Gaming LLC (“we”, “us”) process personal data for it. It adds to the terms of service (the “Agreement”) the terms that Article 28 of the GDPR and of the UK GDPR require, and the safeguards for transferring personal data out of the EEA, the UK and Switzerland.

How to sign it: fill in your organization’s details in the signature block at the end, sign, and send it to support@freero.app. It takes effect when we countersign and send it back. To keep a copy, print this page or save it as a PDF from your browser.

1. Definitions

• “Customer”, “you”: the organization that signs this DPA and uses the service through one or more team workspaces.
• “Customer Personal Data”: personal data in the content and records of your team workspaces that we process for you to provide the service: boards, docs, comments, files, members and their roles, invitations, the workspace audit log, and the accounts of the people you bring into those workspaces as far as the workspaces use them.
• “Data Protection Law”: the laws on personal data that apply to the processing under the Agreement, including the EU General Data Protection Regulation 2016/679 (“GDPR”), the GDPR as it forms part of UK law with the Data Protection Act 2018 (“UK GDPR”), the Swiss Federal Act on Data Protection (“FADP”), and US state privacy laws such as the California Consumer Privacy Act (“CCPA”).
• “Subprocessor”: a company we engage to process Customer Personal Data.
• “Personal Data Breach”: a breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, Customer Personal Data that we process.
• “SCCs”: the standard contractual clauses for the transfer of personal data to third countries adopted by the European Commission in Implementing Decision (EU) 2021/914 of 4 June 2021. “UK Addendum”: the International Data Transfer Addendum to the EU Commission Standard Contractual Clauses issued by the UK Information Commissioner under section 119A of the Data Protection Act 2018 (version B1.0, in force 21 March 2022).
• Controller, processor, data subject, personal data, processing and supervisory authority have the meanings the GDPR gives them.

2. Roles and scope

You are the controller of Customer Personal Data (or a processor acting for your own controller, in which case we are your subprocessor and you pass on to that controller what this DPA gives you). We are your processor. Annex I describes the processing: its subject matter, nature, purpose and duration, and the kinds of data and data subjects.

We are a controller, not your processor, of the personal data we need to run and protect the service itself, as the privacy policy describes: account sign-in and security records, request logs, abuse reports and moderation, problem reports people send us, analytics where a visitor accepts it, and what the law requires us to keep. We use that data only for those purposes.

You are responsible for having a lawful basis for the processing you ask of us, for the instructions you give, and for what your workspaces contain. The service is not designed for special categories of personal data (Article 9 GDPR), data about criminal convictions, payment card data or health records, and you will not use it for them unless we agree in writing.

3. Processing on your instructions

We process Customer Personal Data only on your documented instructions, including for transfers to a third country, unless the law we are subject to requires otherwise; then we tell you before processing, unless that law forbids it. Your instructions are the Agreement, this DPA, and what you and your workspace’s admins do in the service: the content you add, the settings you choose (sharing, retention, single sign-on, provisioning, AI and integrations) and the apps, trackers and webhooks you connect. We tell you if we think an instruction infringes Data Protection Law. We don’t sell Customer Personal Data, use it for advertising, or use it to train AI models.

4. Our people

Only people who need access to provide, support or secure the service may access Customer Personal Data, and only as far as they need it. Each of them is bound by confidentiality. Today the service is run by a very small team; who has administrative access is listed in our records and available to you on request.

5. Security

We implement the technical and organisational measures in Annex II, which take into account the state of the art, the cost of implementation, and the nature, scope, context and purposes of the processing and the risks to individuals (Article 32 GDPR). The security overview describes them in more detail. We may change them, but not in a way that lowers the overall protection of Customer Personal Data.

6. Subprocessors

• You give us general written authorisation to engage Subprocessors. The current ones are on the subprocessor page (Annex III).
• We tell you about any intended addition or replacement at least 30 days before it starts processing Customer Personal Data, by updating that page and emailing the owners of your team workspaces. In an emergency (to keep the service running or secure) the notice may be shorter, and we explain why.
• You may object, on reasonable grounds relating to data protection, within that notice period by writing to support@freero.app. We then discuss it with you in good faith. If we can’t resolve it, you may end the Agreement for the affected workspaces before the change takes effect.
• We put each Subprocessor under a written contract with data protection obligations no less protective than this DPA, as far as they fit the service it provides, and we remain responsible to you for its performance of them.

7. Requests from individuals

Most requests can be handled by your admins in the service itself: admins can see members, export a whole workspace, remove people and content, set retention, and read the audit log; each person can export or delete their own account. Where that isn’t enough, we help you, taking into account the nature of the processing, to answer requests to exercise data subjects’ rights. If a request about Customer Personal Data reaches us directly, we pass it to you without undue delay and don’t answer it ourselves except to say it was passed on, unless the law requires otherwise.

8. Personal data breaches

We notify you without undue delay, and in any case within 72 hours, after becoming aware of a Personal Data Breach. We send the notice to the owners of the affected team workspaces and to any security contact you give us. It describes, as far as we know them 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 for more information. We add what we learn later, take reasonable steps to contain the breach and limit its effects, and help you meet your own obligations to notify authorities and individuals. Notifying you is not an admission of fault.

9. Impact assessments and consultations

We give you the information you reasonably need, about the processing we do for you, for data protection impact assessments and prior consultations with a supervisory authority (Articles 35 and 36 GDPR). The security overview, this DPA and the service’s public source code and documentation are the first part of that information.

10. Return and deletion

• While the Agreement runs, your admins can export a workspace at any time (admin console → Data → Export workspace) and delete boards and whole workspaces. Deleting a workspace takes effect at once.
• When the Agreement ends, you have 30 days to export Customer Personal Data. After that, or sooner on your written request, we delete it from the live service. Copies in database backups are deleted when those backups expire, at most 30 days later, and are not used meanwhile except to restore the service.
• The audit log of a deleted workspace is kept, as a security record, until its retention period ends, unless the law requires us to keep data longer; then this DPA keeps applying to what we keep.

11. Information and audits

We make available the information needed to demonstrate compliance with Article 28 GDPR: this DPA, the security overview, the subprocessor list, written answers to reasonable security questionnaires, and the service’s source code, which is public. We do not hold third-party certifications (such as SOC 2 or ISO 27001) yet.

If that information is not enough, or a supervisory authority requires it, you may audit our compliance with this DPA, yourself or through an independent auditor bound by confidentiality, no more than once a year, with at least 30 days’ written notice, during business hours and without disturbing the service or other customers’ data. You bear the cost of your audit. Audits of our Subprocessors are carried out by means of their own published reports and certifications.

12. International transfers

We are established in the United States, and the service is hosted there (Railway Corporation (United States, US West region)). Where Customer Personal Data is transferred to us from the EEA, Switzerland or the UK and no adequacy decision covers the transfer, the following apply and are incorporated into this DPA by reference:

• EEA: the SCCs, Module Two (controller to processor) where you are a controller, and Module Three (processor to processor) where you are a processor. For those modules: clause 7 (docking clause) applies; under clause 9, option 2 (general written authorisation) applies, with the notice period in section 6 of this DPA; the optional wording in clause 11 does not apply; under clause 13, the competent supervisory authority is that of the EU Member State where you are established or, if you are not established in the EU, where your representative is, or as Annex I says; under clause 17, option 1, the SCCs are governed by the law of Ireland; under clause 18, disputes go to the courts of Ireland. Annexes I, II and III of this DPA are the SCCs’ Annexes I, II and III.
• UK: the SCCs as amended by the UK Addendum. Its Table 1 is completed by Annex I, Table 2 by the choices above, Table 3 by Annexes I to III, and in Table 4 either party may end the UK Addendum as its section 19 allows.
• Switzerland: the SCCs as above, adapted so that references to the GDPR include the FADP, the competent supervisory authority is the Swiss Federal Data Protection and Information Commissioner for transfers under the FADP, and the term “Member State” does not prevent data subjects in Switzerland from suing for their rights where they live.

We are not certified under the EU-U.S. Data Privacy Framework. If the transfer mechanism above is invalidated or replaced, we work with you to put an alternative lawful mechanism in place. If we receive a request from a public authority for Customer Personal Data, we review it for legality, tell you unless the law forbids it, and disclose only the minimum the request lawfully requires.

13. US state privacy laws

Where the CCPA or a similar US state law applies, we are your service provider (or processor) for Customer Personal Data. We process it only for the business purposes in the Agreement; don’t sell or share it (as the CCPA defines those words); don’t retain, use or disclose it outside our direct business relationship with you or for any purpose other than providing the service; don’t combine it with personal data we get from others except as the law permits; comply with the law and give it the protection the law requires; and tell you if we can no longer meet these obligations. You may take reasonable steps to stop and remedy unauthorised use.

14. Liability, term and precedence

• Each party’s liability under this DPA is subject to the limits in the Agreement, except where Data Protection Law or the SCCs do not allow such a limit (for example, liability to data subjects under clause 12 of the SCCs).
• This DPA lasts as long as we process Customer Personal Data for you, including after the Agreement ends until the data is deleted.
• If they conflict, the SCCs (with the UK Addendum where it applies) prevail over this DPA, and this DPA prevails over the Agreement for the processing of Customer Personal Data.
• Apart from the SCCs, which are governed as section 12 says, this DPA is governed by the law that governs the Agreement (the State of Texas, USA).
• We may update this DPA to reflect changes in Data Protection Law or in the service, with at least 30 days’ notice. A change that reduces your protection needs your agreement.

Annex I: parties and the processing

A. Parties

• Data exporter (controller, or processor under Module Three): the Customer, as named in the signature block. Contact person: as given there. Activities relevant to the transfer: using the hosted Freero service.
• Data importer (processor): Kaiten Gaming LLC, 5900 Balcones Drive Ste 100, Austin, TX 78731, United States. Contact: support@freero.app; security contact: security@freero.app. Activities relevant to the transfer: providing the hosted Freero service.

B. Description of the processing and transfer

• Data subjects: the Customer’s members, guests and other people it invites into its workspaces; people mentioned or shown in the content they add (on boards, in docs, comments, files and recordings).
• Categories of personal data: names, email addresses, profile pictures and cursor colours; roles and memberships; content the Customer’s people create or upload (text, drawings, images, PDFs, other files, voice and video in walkthrough recordings); comments, votes and answers in live activities; identifiers from the Customer’s identity provider and directory (SSO subject, SCIM records); security and audit records (sign-ins, sessions with IP address and browser, the actions recorded in the workspace’s audit log, calls made by connected apps); usage counts.
• Sensitive data: none intended (section 2). The restrictions and safeguards that apply are those in Annex II.
• Frequency: continuous, for as long as the Customer uses the service.
• Nature of the processing: hosting, storage, real-time synchronisation and display to the people the Customer lets in, search indexing, version history, exports and backups, sending notification emails, and the integrations the Customer turns on (AI actions, issue trackers, webhooks, connected apps).
• Purpose: providing the service to the Customer under the Agreement.
• Retention: for the term of the Agreement and then as section 10 says. Inside the service, the Customer’s retention settings apply (trash, version history, audit log), and backups expire within 30 days.
• Transfers to Subprocessors: as listed on the subprocessor page, for the purposes listed there and for the duration of the Agreement.

C. Competent supervisory authority

As clause 13 of the SCCs and section 12 of this DPA say; if the Customer has no establishment or representative in the EU, the authority named by the Customer in the signature block. For the UK, the Information Commissioner’s Office; for Switzerland, the Federal Data Protection and Information Commissioner.

Annex II: security measures

A summary; the security overview has the detail, and the source code shows exactly how each is done.

• Encryption in transit: HTTPS only, with HSTS; secure, HttpOnly session cookies; TLS to the email service; connections to the database over the hosting provider’s private network, encrypted with WireGuard, and to the object storage over HTTPS.
• Encryption at rest: passwords stored as scrypt hashes and tokens as SHA-256 hashes; secrets such as two-step verification keys, single sign-on client secrets, AI keys and integration credentials sealed with AES-256-GCM under a rotatable key; the database, its backups and files encrypted at rest (AES-256) by the hosting provider.
• Access control: every request and live connection is checked on the server against the person’s role on the board and the workspace’s policies; workspaces can require two-step verification, enforce single sign-on, provision and deprovision through SCIM, and limit session length and idle time; administrative access to the production systems is limited to the operator’s staff who need it, on accounts that require two-step verification.
• Separation of customers: one shared database with every read and write checked against the requester’s access; content the server withholds (private drafts, hidden frames) never reaches people, apps or indexes that may not see it.
• Logging and audit: an append-only, hash-chained audit log per workspace with signed hourly checkpoints, an integrity check, export, and streaming to the Customer’s SIEM; request logs without request bodies, query strings, cookies or tokens.
• Availability and recovery: automated database backups kept up to 30 days, health-checked rolling deploys, restart on failure; a restore from backup tested at least once a quarter.
• Secure development: automated type checks, architecture checks and tests on every change, a container smoke test before deploys, public source code, and a published vulnerability disclosure policy.
• Incidents: a documented response procedure and the notification commitment in section 8.

Annex III: subprocessors

The list on the subprocessor page, as it stands when the DPA is signed and as updated under section 6.

Signatures

Signed by the authorised representatives of the parties.