Data Processing Agreement
Effective date: August 10, 2026
Last updated: August 10, 2026
This Data Processing Agreement ("DPA") forms part of the Terms of Service between Pixelmatters, Unipessoal, Lda. (Avenida dos Aliados, nº 168, 4º Andar, 4000-064 Porto, Portugal — the "Processor") and the account holder using the hosted Markup service (the "Controller"). It applies automatically to every account — no signature or separate request is needed — and governs all processing of personal data that the Controller collects through the service, wherever the GDPR or equivalent law applies to it.
If you need a countersigned copy for your records, email hello@pixelmatters.com.
1. Roles and scope
The Controller decides why and how end-user feedback is collected on its sites; the Processor processes that data only to provide the service. The data concerned, its subjects and the processing operations are described in Annex I. For dashboard account data (the Controller's own team members' accounts), Pixelmatters is an independent controller as described in the Privacy Policy — that data is outside this DPA.
2. Processor obligations
The Processor shall:
- Follow instructions. Process personal data only on the Controller's documented instructions — which are: provide the service as configured by the Controller in its project settings — unless EU or member-state law requires otherwise, in which case the Processor informs the Controller before processing (unless the law forbids that).
- Bind its people. Ensure everyone it authorises to process the data is under a contractual or statutory duty of confidentiality.
- Secure the data. Implement and maintain the technical and organisational measures in Annex II, and not degrade them during the term.
- Help with data-subject requests. The service builds the common ones in — self-serve erasure for commenters, tombstoning erasure on account deletion, per-project export for access and portability. For requests these tools don't cover, the Processor provides reasonable assistance within the 30-day GDPR window.
- Help with the Controller's own obligations. Provide reasonable assistance with security, breach notification, DPIAs and prior consultation (Arts. 32–36 GDPR), taking into account the nature of the processing.
- Report breaches. Notify the Controller without undue delay, and in any case within 72 hours, after becoming aware of a personal-data breach affecting the Controller's data, with the information Art. 33(3) GDPR requires as it becomes available.
- Delete or return. On termination of the account or deletion of a project, delete the personal data as described in the Privacy Policy's retention section, unless law requires longer storage. Export tooling is available before deletion.
- Demonstrate compliance. Make available the information reasonably necessary to demonstrate compliance with Art. 28 GDPR. The service's source code being public satisfies much of this transparently; beyond that, the Processor answers reasonable written audit questionnaires at most once per year, and permits audits required of the Controller by a supervisory authority.
3. Sub-processors
The Controller gives general written authorisation to the sub-processors listed at /legal/subprocessors. The Processor:
- flows down data-protection obligations no weaker than this DPA's to every sub-processor, and remains fully liable for their performance;
- announces additions or replacements by updating that page at least 14 days before the new sub-processor touches Controller data (the page's git history provides a verifiable record, and the repository can be watched for changes);
- if the Controller objects on reasonable data-protection grounds and no resolution is found, allows the Controller to terminate and export — per section 9 of the Terms, that path is always open anyway.
4. International transfers
Personal data is processed in the locations listed at /legal/subprocessors. Where processing leaves the EEA, the transfer relies on an adequacy decision (including the EU–US Data Privacy Framework for certified providers) or on Standard Contractual Clauses incorporated in the relevant sub-processor's data-processing terms. The Processor will not transfer Controller data to a country lacking such safeguards.
5. Liability and precedence
Liability under this DPA is subject to the limitations in the Terms of Service, except where the GDPR does not permit them to apply. If this DPA conflicts with the Terms, this DPA prevails for data-protection matters.
Annex I — Description of processing
Subject matter and purpose. Operating an in-page feedback service: collecting, storing, and displaying feedback left by the Controller's end users on the Controller's websites, and delivering the notifications the Controller configures.
Duration. The life of the Controller's account, plus the deletion windows in the Privacy Policy's retention table.
Nature of processing. Collection via the embedded widget; storage; display to the Controller's project members; optional relay to the Controller's Slack workspace; erasure and export on request.
Categories of data subjects. End users of the Controller's websites who interact with the widget; the Controller's project members appear as recipients rather than subjects of this processing.
Categories of personal data.
| Category | Detail |
|---|---|
| Identity (self-declared) | Display name typed by the commenter; email if volunteered; for verified commenters, name/email from their sign-in |
| Pseudonymous identifiers | Random per-site commenter id; token identifiers |
| Content | Comment text; screenshots the commenter attaches (sensitive-looking fields are redacted client-side before capture, but screenshots may incidentally contain whatever the page showed) |
| Technical context | Page URL and route, viewport size, browser user-agent |
Special categories. None are sought or required. The Controller must not direct end users to submit special-category data through the widget; free-text and screenshots may incidentally contain what end users choose to put there, which the Controller stewards as controller.
Annex II — Technical and organisational measures
- Tenant isolation. Every backend function resolves and enforces project membership; widget requests are scoped to a single project by their credential and cannot address another tenant.
- Encryption. TLS for all data in transit; encryption at rest provided by the database layer (Convex, on AWS infrastructure).
- Credential hygiene. API keys stored as SHA-256 hashes only, displayed once at creation; revocable at any time. Widget sessions use short-lived signed JWTs (15-minute access, 7-day rotating refresh) with a server-side revocation list and a "sign out everywhere" control.
- Origin control. A per-project domain allowlist restricts where the widget authenticates from; production requests from unlisted origins are refused.
- Abuse resistance. Per-credential rate limiting on widget and MCP endpoints; webhook destinations restricted to Slack's endpoints; widget telemetry event names allowlisted server-side.
- Client-side data minimisation. Screenshot capture blacks out password, payment-card and one-time-code fields before the image is created; error and telemetry relays strip end-user identifiers.
- Auditability. Security-relevant actions are written to a per-project audit log; erasures are confirmed in the log without re-recording the erased identity. The full codebase is open source and independently auditable.
- Data lifecycle. Automated sweeps remove expired tokens, revocation records, exchange codes and unattached uploads; deletion and erasure flows tombstone rather than orphan shared content.
- Organisational. Access to production systems is limited to authorised Pixelmatters personnel bound by confidentiality, on a need-to-use basis; a documented backup/export runbook covers recovery.