Data Processing Agreement
Annex to the Lifesizy Terms of Service. This agreement forms part of the service terms between the Shop and CasMaster. It applies automatically from the moment the Shop’s account is activated; no separate signature is needed, though we will countersign a copy on request for the Shop’s compliance file.
Written to be read: a shop owner should get through this in fifteen minutes. Where the GDPR requires specific content (Article 28(3)), the article is named so your auditor can find it.
- Processor
- CasMaster, trading as Lifesizy, Steenenbaak 20, 2134 XG Hoofddorp, the Netherlands. KvK 88292800. Contact: hello@lifesizy.com.
- Controller
- The print shop that holds the Lifesizy subscription (the “Shop”), as identified in its account.
- Version
- 1.4, of 15 August 2026.
1. What this agreement covers
Subject matter, duration, nature, purpose.
- Subject matter. Lifesizy processes photos that the Shop’s customers upload, to generate cutline previews and press-ready die-cut production PDFs, on the Shop’s behalf.
- Duration. As long as the Shop’s subscription runs, plus the wind-down period in section 10.
- Nature of the processing. Receiving an uploaded photo, removing its background, tracing a cutline, rendering a preview, generating a production PDF, and, for hosted-portal orders and for paid orders the Shop’s WooCommerce store syncs to the Lifesizy dashboard, storing the photo and order details temporarily. In the WooCommerce case the photo and order facts are sent to us server-to-server by the Shop’s own WordPress installation, authorised by the Shop’s connect key.
- Purpose. Solely to deliver the Lifesizy service to the Shop: one photo in, one cutline and one PDF out. Nothing else.
2. Whose data, and what data
Art. 28(3) opening.
- Data subjects: the Shop’s customers and the people appearing in the photos they upload: identifiable people, sometimes including children.
- Data categories: the uploaded photo (an image of a person is personal data), the chosen cutout size, an order reference (typed by the customer on the hosted portal, or the order number from the Shop’s own webshop for synced orders), the customer’s recorded cutline approval, and technical request metadata (timestamps, IP address in transient logs).
- No special categories. Lifesizy performs no facial recognition or identification of any kind. Ordinary photos of people are therefore not special-category data. If the Shop intends to send photos that are inherently special-category (for example, clearly revealing health data), that is the Shop’s call as controller and the Shop must tell us first.
3. Documented instructions
Art. 28(3)(a).
We process the photos only on the Shop’s documented instructions. The instructions are: this agreement, the Terms of Service, and the configuration the Shop sets in its Lifesizy account (sizes, output profile, portal on or off). We will not process for any other purpose. If we believe an instruction violates the GDPR, we tell the Shop before carrying it out. If EU or Dutch law ever requires us to process differently, we inform the Shop first unless that law forbids it.
4. No training, no reuse. Ever.
We never use the Shop’s customers’ photos to train, fine-tune, or evaluate any model, and never reuse them for our own purposes: not for marketing, not for analytics, not for product demos, not in anonymised or aggregated form. A photo exists in our systems only to produce that Shop’s cutline and PDF. This clause survives termination of the agreement.
5. Confidentiality
Art. 28(3)(b).
Everyone we authorise to access the Shop’s data (currently: the founder who runs CasMaster/Lifesizy) is bound to confidentiality by contract or by their role, and access is limited to what operating the service requires.
6. Security
Art. 32, Art. 28(3)(c).
Measures in place, honestly described. We hold no ISO or SOC 2 certification and do not claim one:
- Stateless preview engine: preview generation runs in memory and stores nothing. Photos sent through the widget or the WooCommerce plugin for a preview are discarded the moment the preview is returned.
- EU storage: photos we store for orders (hosted portal and WooCommerce order sync) live in an EU region (Frankfurt); see the sub-processor list.
- Tenant isolation: each Shop’s data is partitioned per shop; one Shop can never read another Shop’s orders or photos.
- Hashed credentials: connect keys and account credentials are stored hashed, never in plain text.
- Upload sanitization: uploads are strictly validated for type, size and content before the image parser touches them, and every photo, rendered or stored, has its EXIF and GPS metadata stripped before we persist it.
- Rate limiting and size caps on all endpoints that accept input, against abuse and cost attacks.
- Encryption in transit (TLS) on every connection.
We may improve these measures over time; we will not reduce the overall level of protection during the term.
7. Sub-processors
Art. 28(2), 28(3)(d).
The Shop gives general written authorisation for the sub-processors on our sub-processor list, which is published on our trust page and available on request at any time. For each of them we have, or conclude before first use, a data processing agreement imposing the same obligations as this one; we remain fully liable to the Shop for their performance.
That list has a scope marker, and only the vendors marked “shop data” are sub-processors under this agreement. The remaining vendor is a model provider used for our own internal business summaries, where CasMaster is itself the controller (our own operating numbers and customer administration): it never receives photos, order contents, order references or any other data we hold on the Shop’s behalf, and the “no training, no reuse” commitment in section 4 is absolute and is enforced in code, not by policy alone.
Changes:we notify the Shop by e-mail at least 14 days before adding or replacing a sub-processor that touches the Shop’s data. The Shop may object on reasonable data-protection grounds; if we cannot resolve the objection, the Shop may terminate the subscription for the remaining period without penalty.
8. Assisting the Shop
Art. 28(3)(e) and (f).
- Data subject requests (access, erasure, and the rest of Chapter III) go to the Shop; the Shop has the customer relationship. If a request reaches us directly, we forward it to the Shop without answering it ourselves. On the Shop’s instruction we delete or hand over a specific customer’s photo and order data without undue delay.
- How erasure works in practice today, stated plainly. A submission the Shop has not confirmed can be declined in the Shop’s dashboard, which deletes the photo immediately. For an order the Shop has already confirmed, the dashboard has an erase action (since August 2026): the photo is deleted and the order row stays as the Shop’s own business record. WordPress’s own erase-personal-data flow, which our WooCommerce plugin plugs into, clears the photo on the Shop’s server AND asks us to delete our copy in the same run, from plugin version 0.4.0 onwards. An older plugin clears only the Shop’s own copy, so on those the dashboard action is the second step. In every path, if the deletion cannot be completed we report a failure rather than a success, so the Shop is never told an erasure happened that did not. E-mailing us still works and we act without undue delay. Everything left over is deleted automatically 30 days after we received it.
- We assist the Shop, to the extent the information is in our hands, with its Art. 32 to 36 duties: security, breach notification, and, should the Shop ever need one, a data protection impact assessment. Routine assistance is included; genuinely extensive requests may be billed at a reasonable rate, announced in advance.
9. Personal data breaches
If we become aware of a personal data breach affecting the Shop’s data, we notify the Shop without undue delay and at the latest within 48 hours of becoming aware, with the information the Shop needs for its own Art. 33 notification: the nature of the breach, the categories and approximate numbers of data subjects and records, the likely consequences, the measures taken or proposed, and a contact point. We update the notice as facts firm up rather than waiting for a complete picture. The Shop’s own 72-hour clock towards its supervisory authority starts when the Shop becomes aware, which is why we commit to well inside that window.
10. Deletion and return at the end
Art. 28(3)(g).
Stored order photos, from the hosted portal and from WooCommerce order sync alike, are deleted automatically 30 days after we receive them, throughout the term. When the subscription ends, the Shop has 30 daysto download any stored photos and order data it still needs; after that window we delete all of the Shop’s customer data, unless EU or Dutch law requires us to keep something (in which case we keep only that, only as long as required). On written request we confirm deletion.
One concrete instance of that legal exception, stated plainly rather than hidden behind the sentence above: where an order sits above the Shop’s included volume and is listed on an invoice as “unlocks on payment”, that invoice line names the order’s reference. Dutch tax law makes us keep invoices for seven years, so that single reference outlives the 30-day deletion of the order itself. No photo, no approval evidence and no other customer data goes into the invoice archive. We are changing the invoice generator to use our own internal order id instead; until then, this is what happens.
11. Audits
Art. 28(3)(h).
We make available the information reasonably necessary to demonstrate compliance with this agreement: this document, the sub-processor list, our security documentation, and written answers to reasonable questions. If that does not satisfy the Shop, the Shop (or an auditor it mandates, not a competitor of ours) may audit once per twelve months, on at least 30 days’ written notice, during business hours, without disrupting the service. Each side bears its own costs; if the Shop wants more than one audit per year without a concrete indication of non-compliance, the extra audit is at the Shop’s cost including our reasonable time.
12. Liability, law, precedence
- Liability under this agreement follows the cap and exclusions in the Terms of Service; this agreement does not create a separate or higher cap.
- Dutch law governs this agreement; disputes go to the competent court in the Netherlands, as in the Terms of Service.
- If this agreement conflicts with the Terms of Service on a data-protection point, this agreement wins on that point.
- International transfers: photo storage stays in the EU. Where a sub-processor involves a transfer outside the EEA (see the sub-processor list), it is covered by an adequacy decision and/or Standard Contractual Clauses.
Version 1.4, 15 August 2026. To keep a copy for your compliance file, print or save this page as PDF, or ask us to countersign one at hello@lifesizy.com. See also our trust page, privacy notice and terms of service.