Status of this document
This page sets out the structure that data processing terms for Dynodoc would follow. It is a draft, not an executed agreement; it is not offered for signature, and nobody becomes bound by it by using the service. It describes how the service behaves today, as already stated in the privacy policy, the terms and the security overview, and it leaves anything that needs a legal decision as an open item. It adds no commitment of its own.
Parties and roles
- Customer: the organization or person that decides what is uploaded to its projects, who is a member and how long content is kept. For that content the customer is generally the controller, or a processor acting for its own clients.
- Operator: the legal operator of the hosted service, not yet identified. For project content it would act as a processor on the customer’s instructions. For account and service-operation records, security logs and anonymous performance measurements it decides how and why information is processed.
The roles actually applicable depend on the law that governs the arrangement. A person who uses the service in their own capacity is covered by the privacy policy directly.
Subject matter, duration and purpose
Subject matter: hosting, storing, converting, displaying, backing up and otherwise processing documents and project history so that the customer can capture, review, merge, recover and verify changes. Purpose: providing the features the customer requests, applying its sharing settings, maintaining and securing the service and meeting legal obligations. Content is not sold, used for advertising or used to train AI models. Duration: while the account or project exists, followed by the retention and erasure described in the privacy policy.
Information and people
| Category | Examples |
|---|---|
| Document content | Text, cells, slides, formatting, comments, suggestions and original uploads. |
| Project structure | Project, folder and file names and member roles. |
| Account identifiers | Email address, display name and account identifier. |
| History and provenance | Authors, timestamps, hashes, signed commits, branch receipts and drafts. |
| Audit and connection records | Administrative actions, erasure receipts and editor connection grants. |
The people concerned are the customer’s members and invited collaborators and anyone named or described in a document. Dynodoc does not decide what documents contain. Special categories of information are not intended content; the customer is responsible for what it uploads, as the terms say under sensitive and regulated information.
Processing instructions
The service processes project content only to provide the features the customer uses, as configured through roles, project rules, shared links and erasure requests. The final agreement must say how further written instructions are given, and what happens when an instruction would be unlawful.
Security measures
The measures that exist are described, with their limits, in the security overview. In summary: a hash-chained append-only history, checked snapshots, a restricted database login, revocable sessions, scoped and expiring editor connection keys, HTTPS with a strict content policy, request limits, hardened containers, validated backups and audited whole-document erasure. The same page lists what is not claimed, including independent audit, certification and off-site backups.
Subprocessors
The current providers are listed on the subprocessors page. The final agreement must say how a change to that list is announced and whether the customer may object.
Assistance, incidents and requests
A customer can export supported files and see its own members’ access. Administrators can erase a whole document or account as described in the privacy policy; there is no self-service erasure today. If a personal-data incident occurs, the operator and the customer must assess it and meet applicable notification duties. The final agreement must set the timelines and the form of assistance with data-subject requests and impact assessments; this draft invents none.
Deletion and return
- Return: while access lasts, a customer can download supported files and retained revisions under their permissions. If the service is discontinued, the terms propose a reasonable opportunity to export.
- Deletion: an administrator can erase a whole document or an account. A minimal receipt, a deleted-account identity and public signing-key bindings stay so that remaining history verifies. Individual past changes cannot be redacted from a retained history.
- Backups: database backups are kept for a rolling 14 days on the same server and expire on that schedule.
Audit and records
The service keeps an operations log and erasure receipts, and a customer with access to a document can ask the service to verify the integrity of its history. The source code is available under an open-source license so that behaviour can be inspected; see licenses. No independent audit or certification exists. The final agreement must state any audit right, how it is exercised and who bears its cost.
Location and transfers
The hosting provider and the locations where information is stored are awaiting confirmation. Safeguards for any transfer outside the customer’s jurisdiction must be identified before these terms are completed.
Open items
- Legal operator, address and governing law.
- Hosting provider, storage locations and transfer safeguards.
- How instructions are given and how an unlawful instruction is handled.
- How subprocessor changes are announced and objected to.
- Incident-notification and assistance timelines.
- Audit rights and cost.
- Retention for administrative logs and web server logs.
- Liability allocation, reviewed with the final terms.