Data Processing Agreement
Last updated [EFFECTIVE DATE]
This agreement sets out how moqtap processes personal data on behalf of its customers, as Article 28 of the GDPR requires. It is part of the Terms of Service and applies automatically to every customer who accepts them. Nothing needs to be signed.
If your procurement process needs a signed copy, email hello@moqtap.com with your organisation's legal name and address, and we will send this agreement as a PDF countersigned by moqtap. The signed copy has the same terms as this page.
1. Parties and definitions
The parties are the customer, as defined in the Terms, and [ENTITY], [ADDRESS], registered under [REGISTRATION] ("moqtap").
- Customer Data means the personal data described in Annex 1 that moqtap processes on the customer's behalf when providing the service.
- GDPR means Regulation (EU) 2016/679. "Personal data", "processing", "controller", "processor", "data subject", "personal data breach" and "supervisory authority" have the meanings given in it.
- Data protection law means the GDPR and the laws that implement or supplement it, and, where they apply, the UK GDPR and the Swiss Federal Act on Data Protection.
- SCCs means the standard contractual clauses adopted by the European Commission in Implementing Decision (EU) 2021/914.
- Sub-processor means another processor that moqtap engages to process Customer Data.
2. Roles
- For Customer Data, the customer is the controller and moqtap is its processor. If the customer is itself a processor for someone else, moqtap is its sub-processor, and the customer confirms that its controller has authorised this agreement, including the sub-processors in Annex 3.
- moqtap is a controller, not a processor, for the data it needs to run accounts: who each user is, how they sign in, their devices and sessions, which workspaces they belong to, billing records, and the records it keeps to secure the service, including each workspace's security log, which the workspace's owners can read and export. The privacy page describes that processing. moqtap is also the controller for traces in a personal workspace, as set out on the trust page.
- The customer is responsible for having a lawful basis for the Customer Data it sends to moqtap, and for giving data subjects the information the law requires.
3. Processing only on instructions
moqtap processes Customer Data only on the customer's documented instructions. These are: the Terms and this agreement; what the customer does in the service, such as uploading a trace, setting a retention period, creating or revoking a share link, adding or removing a member, or deleting data; and any other written instruction the parties agree.
If the law requires moqtap to process Customer Data in another way, moqtap tells the customer first, unless that law forbids it. moqtap tells the customer straight away if it believes an instruction breaks data protection law.
4. Confidentiality
Only people who need access to run, support or secure the service can access Customer Data, and each of them is bound by a duty of confidentiality, by contract or by law.
5. Security
moqtap applies the technical and organisational measures in Annex 2 to protect Customer Data, as Article 32 of the GDPR requires. It may change those measures, but not in a way that lowers the overall protection of Customer Data.
6. Sub-processors
- The customer gives moqtap general authorisation to engage sub-processors. The current ones are listed on the trust page (Annex 3).
- moqtap announces a new sub-processor on that list at least 30 days before it starts processing Customer Data.
- The customer can object to a new sub-processor on reasonable data protection grounds by emailing hello@moqtap.com within those 30 days. moqtap will then work with the customer in good faith to resolve the objection, for example by not using that sub-processor for the customer's data.
- If the objection cannot be resolved, the customer may terminate the service the new sub-processor affects, and moqtap refunds the prepaid fees for that service for the period after termination.
- moqtap puts data protection obligations on each sub-processor that give at least the protection required by this agreement, and it remains responsible to the customer for how each sub-processor meets them.
7. Helping the customer
- Requests from data subjects. If a data subject asks moqtap to exercise a right over Customer Data, moqtap passes the request to the customer and does not answer it except on the customer's instructions. The service lets the customer find, download and delete traces, revoke share links, and delete a whole workspace with its telemetry. Where that is not enough, moqtap helps on request.
- Impact assessments and consultations. moqtap gives the customer the information it reasonably needs about the service for a data protection impact assessment or a prior consultation with a supervisory authority.
- Security and breaches. moqtap helps the customer meet its obligations under Articles 32 to 34 of the GDPR, taking into account the nature of the processing and the information available to moqtap.
8. Personal data breaches
moqtap notifies the customer of a personal data breach affecting Customer Data without undue delay, and in any case within 48 hours of becoming aware of it. The notice goes to the owners of the affected workspace by email. It describes, as far as moqtap then knows, the nature of the breach, the categories and approximate number of data subjects and records concerned, the likely consequences, and the measures taken or proposed. moqtap adds to it as it learns more, and takes reasonable steps to contain the breach and limit its effects.
Notifying a breach is not an admission of fault or liability.
9. Information and audits
- moqtap makes available the information needed to show that it meets this agreement. That starts with this agreement, its annexes and the trust page. moqtap also answers a customer's reasonable written security questions, once a year, and shares the certifications and audit reports of its sub-processors where their terms allow it.
- If that information is not enough, the customer may carry out an on-site audit only where a supervisory authority requires it, or after a personal data breach affecting Customer Data.
- An on-site audit needs at least 30 days' written notice. It takes place in business hours, is carried out by the customer or an independent auditor bound by confidentiality, must not give access to other customers' data, and is at the customer's cost.
10. Deletion and return at the end
Throughout the service, the customer can download its traces. When the customer deletes data, or deletes a workspace, or its account ends, moqtap deletes the Customer Data concerned:
- a deleted trace stops being available at once, and the trace and its share links are removed within days;
- deleting a team workspace deletes its traces, scenarios, share links and telemetry;
- the telemetry of a deleted Insight project, workspace or account is removed within 14 days;
- a deleted account is removed 30 days after deletion;
- backups are kept for up to 35 days, and deleted data remains in them until they age out.
The customer should download what it wants to keep before deleting it. moqtap keeps Customer Data beyond these periods only where EU or member state law requires it, and then only for as long as it requires.
11. International transfers
Customer Data is stored in the EU: in Cloudflare's EU jurisdiction, which keeps it in EU data centres, and on a server in Helsinki, Finland. Cloudflare answers each request from a data centre near the person making it, so Customer Data in transit can pass through Cloudflare data centres outside the EU, and Cloudflare, Inc. is in the United States. Those transfers are made under Cloudflare, Inc.'s certification to the EU–US Data Privacy Framework, and under the SCCs, Module 3 (processor to processor), in moqtap's agreement with Cloudflare.
Where the customer is outside the European Economic Area, in a country without an adequacy decision, and moqtap makes Customer Data available to it, the SCCs, Module 4 (processor to controller), apply between moqtap as data exporter and the customer as data importer. They are incorporated into this agreement by reference, with the docking clause (Clause 7) included, and with Clause 17 governed by the law of [GOVERNING LAW] and disputes under Clause 18 resolved by the courts of [COURTS].
For transfers subject to the UK GDPR, the International Data Transfer Addendum issued by the UK Information Commissioner applies alongside the SCCs. For transfers subject to the Swiss Federal Act on Data Protection, references in the SCCs to the GDPR are read as references to that Act, and the Swiss Federal Data Protection and Information Commissioner is the competent supervisory authority.
moqtap does not transfer Customer Data outside the EU in any other way without telling the customer through the sub-processor notice in section 6.
12. Liability
Each party's liability under this agreement is subject to the limitation of liability in the Terms. That limitation does not restrict a data subject's rights under Article 82 of the GDPR or under the SCCs.
13. Order of precedence and duration
If they conflict, the SCCs take precedence over this agreement, and this agreement takes precedence over the rest of the Terms. This agreement lasts as long as moqtap processes Customer Data for the customer. moqtap may change it under the same notice rules as the Terms, but a change may not lower the protection of Customer Data unless the law requires it.
Annex 1: Details of the processing
| Subject matter | Hosting and processing Customer Data so that moqtap can provide the service described in the Terms. |
| Duration | For as long as moqtap processes Customer Data for the customer, and then until it is deleted as described in section 10. |
| Nature of the processing | Receiving, storing, indexing, analysing and displaying Customer Data; building analytics from telemetry; making traces available through share links the customer creates; keeping backups; deleting data when its retention period ends or the customer deletes it. |
| Purpose | Letting the customer capture, store, inspect, share and monitor media delivery over Media over QUIC and WebTransport, and keeping the service secure. |
| Data subjects | People who use the customer's applications and whose sessions are measured by Insight telemetry or recorded in a trace; other parties to a recorded session, such as relays and publishers; the customer's own staff and collaborators who are members of its team workspaces. |
| Special categories | None intended. The service is not designed for special categories of personal data, and the customer should not send them. |
Categories of personal data
- Insight telemetry
- What the customer's applications send to moqgest.com: session and segment identifiers, any user, actor or content identifiers the customer chooses to include, track and namespace names, timings and delivery statistics. For each upload, moqtap also records the page origin and the browser's user-agent string (each cut to 256 bytes) and the country the request came from. The IP address is used to work out that country and is not stored.
- Traces, scenarios and notes in a team workspace
- Whatever the recorded MoQT or WebTransport session carried and the customer chose to upload. That can include identifiers, authentication tokens, track names and payloads of the customer's users and of other parties to the session, together with the names and notes the customer adds.
How long it is kept
| Insight telemetry | 30 days on the Free plan; within 14 days of deleting its project, workspace or account |
| Analytics built from telemetry | 90 days; within 14 days of deleting its project, workspace or account |
| Traces in a team workspace | Set by the customer; 90 days by default |
| Share links | 1 to 90 days, chosen when the link is made; revocable at any time; the record is deleted 30 days after expiry or revocation |
| Backups | Up to 35 days |
Annex 2: Technical and organisational measures
Signing in and access
- There are no passwords. Users sign in with GitHub, Google, or a one-time code sent by email.
- The web session cookie is restricted to app.moqtap.com and cannot be read by page script. A session ends after 7 days without use, and after 30 days at most.
- The extension and the command-line tool get their own credentials, which are signed, expire after an hour and are renewed with a refresh token. Reuse of an old refresh token revokes it. Users see every signed-in browser and client under Devices, and can sign any of them out.
- Sensitive actions, such as connecting a new sign-in method or exporting a security log, need a fresh sign-in.
- Every request is checked against the user's role in the workspace it touches. A credential issued for one workspace cannot reach another.
- Removing a member from a team workspace revokes their access to it, and lets the owners review the share links that member created.
Records of access
- Every download of a trace from a library, and every export of a security log, is recorded in that workspace's security log before it happens. If the record cannot be written, the download or export is refused.
- Sign-ins, membership changes and share changes are recorded in the same log.
- Workspace owners can read and export their workspace's security log.
Handling untrusted content
- Only signed-in users can upload traces. Each upload is checked against the trace format and size limits before it is stored.
- Traces are displayed by a viewer on its own domain, moqtapusercontent.com, which holds no sign-in. Its scripts cannot send data to any server, because its security policy allows no network connections, and it cannot read the user's other data.
- A share link's secret is kept in the part of the URL that browsers do not send to the server. Every share link expires within 90 days and can be revoked.
- The account pages run under a strict Content Security Policy.
Encryption and storage
- All connections to the service use TLS.
- Data stored with Cloudflare is encrypted at rest by Cloudflare.
- Backups kept on the server in Helsinki are encrypted to a key held offline.
- Databases can be restored to any point in the last 30 days, and daily backups are kept for up to 35 days.
Data minimisation and deletion
- Telemetry collection stores the country a request came from, not its IP address.
- The security log keeps only the first part of an IP address, and removes it, with the country, after 90 days.
- Scheduled jobs delete data when its retention period ends, as listed in Annex 1.
Operations
- Administrative access to production (the hosting and domain account, the code repositories, the sign-in provider configuration and the mailbox) requires a hardware security key, and automated deployments use credentials limited to what each one needs.
- Test environments run on separate domains and separate databases from production.
- Security issues can be reported to security@moqtap.com.
Annex 3: Sub-processors
The current list of sub-processors, what each does and where, is on the trust page. Of those, Cloudflare, Inc. and Hetzner Online GmbH process Customer Data. GitHub and Google take part only when a user chooses to sign in with them, and receive no Customer Data. Changes to the list follow section 6.
Questions about this agreement, or a request for a signed copy? Write to hello@moqtap.com