PageWard ← Back to site
Legal

Data Processing Agreement

The Art. 28 GDPR agreement governing PageWard's processing of personal data on behalf of a customer. It forms part of the Terms of Service.

Last updated: 4 August 2026 · Version 0.1 (draft)

⚠ Draft template — not yet in force

A working draft for legal review. It has not been reviewed by anyone legally qualified, and it is not yet offered to customers as an executed agreement.

Being blunt about why that matters: PageWard already processes personal data on behalf of pilot partners, and Art. 28(3) requires a contract for that now — the obligation does not wait for the first invoice. Closing that gap is what this document is for.

1. Parties and structure

This Agreement is between the Customer (the "Controller") and Jeremy Cabaret, operating PageWard (the "Processor"), TO FILL — address, Obertrum am See, Austria.

It applies whenever PageWard processes personal data on the Customer's behalf in providing the service. Where this Agreement and the Terms of Service conflict on data protection, this Agreement prevails.

2. Roles — the controller/processor split

Decision recorded

An earlier version of our public documentation claimed processor status for uploaded content while asserting PageWard's own Art. 6(1)(f) legitimate interest in the view log. Those two positions are incompatible: a processor has no Art. 6 basis of its own, and determining a purpose would convert us into a controller under Art. 28(10). The split below resolves it in the cleaner direction.

DataOur roleBasis
Uploaded page content and any personal data inside itProcessorThis Agreement
Viewer allowlists (email addresses the Customer invites)ProcessorThis Agreement
View log — who opened which page, and whenProcessorThis Agreement. The log exists to give the Customer visibility over their own content; we do not determine its purpose and do not use it for our own ends.
Account data — name, email, authentication, org membershipControllerPrivacy Policy
Billing records and invoicesControllerContract and statutory retention
Security and abuse logs, and platform-level operational metricsControllerArt. 6(1)(f) — securing and operating the service

Each party complies with the GDPR in respect of its own role. The Customer warrants that it has a lawful basis for the personal data it puts into PageWard, and that it has given the notices its own data subjects are due — including, where relevant, the Art. 14 notice owed to a person added to an allowlist by someone else.

3. Processor obligations (Art. 28(3))

We shall:

  1. (a) Process only on documented instructions from the Customer, including on international transfers, unless required otherwise by EU or Member State law — in which case we inform the Customer before processing, unless that law prohibits it. Using the service as documented, and this Agreement, constitute the Customer's complete documented instructions. We will tell the Customer if we consider an instruction to infringe the GDPR.
  2. (b) Confidentiality — every person authorised to process the Customer's personal data is bound by an obligation of confidentiality. TO FILL — today the only such person is the operator; a written confidentiality undertaking must be in place for any future employee or contractor before access is granted.
  3. (c) Security — implement the technical and organisational measures required by Art. 32. Those measures are set out in Annex II.
  4. (d) Sub-processors — engage them only under the conditions in §4, imposing the same data protection obligations by contract, and remaining fully liable for their performance.
  5. (e) Data subject rights — assist the Customer with appropriate technical and organisational measures, insofar as possible, in responding to requests to exercise rights under Chapter III. Where a request reaches us directly, we forward it to the Customer and do not respond substantively ourselves.
  6. (f) Assistance — assist the Customer in complying with Arts. 32–36: security, breach notification to the supervisory authority and to data subjects, data protection impact assessments and prior consultation, taking into account the nature of processing and the information available to us.
  7. (g) Deletion or return — at the Customer's choice, delete or return all personal data at the end of the service, and delete existing copies, unless EU or Member State law requires storage. See §7.
  8. (h) Audit — make available all information necessary to demonstrate compliance with Art. 28, and allow for and contribute to audits, including inspections, conducted by the Customer or an auditor it mandates. See §8.

4. Sub-processors

The Customer gives general written authorisation for the sub-processors listed in Annex III.

We will give the Customer at least 30 days' notice before adding or replacing a sub-processor, by email to the account's billing contact. The Customer may object on reasonable data protection grounds within that period. If we cannot resolve the objection, the Customer may terminate the affected service without penalty and receive a pro-rata refund of prepaid fees.

TO FILL — a notification mailing list does not exist yet. Until one does, notice will be sent directly to each customer.

5. International transfers

Personal data is stored in the European Union — Supabase in eu-central-1 (Frankfurt), Vercel serverless functions pinned to fra1 (Frankfurt).

One honest exception. Vercel Edge Middleware, which refreshes the session cookie, runs at Vercel's global edge network and may therefore execute outside the EU. It validates the authentication token and sees the signed-in user's identifier and email address. It does not handle page content. Where this or any sub-processor arrangement involves a transfer to a third country, it is carried out under the European Commission's Standard Contractual Clauses (Implementing Decision (EU) 2021/914), together with any supplementary measures a transfer impact assessment identifies as necessary.

Copies of the transfer safeguards relied upon are available on request to privacy@pageward.dev.

DECIDE — whether to eliminate this exception by removing the middleware's dependency on user identity, which would make the EU-residency story unqualified. Worth doing before the first enterprise security review, since this is exactly the clause a reviewer will find.

6. Personal data breaches

We will notify the Customer without undue delay, and in any event within 48 hours, after becoming aware of a personal data breach affecting their data, with the information available to us: the nature of the breach, the categories and approximate number of data subjects and records concerned, likely consequences, and the measures taken or proposed.

Where full information is not available at once, we provide it in phases without undue further delay. We do not notify the Customer's supervisory authority or data subjects on the Customer's behalf unless instructed to.

7. Deletion and return

8. Audits

We will respond to reasonable written information requests, including security questionnaires, needed to demonstrate compliance. The Customer may audit on 30 days' notice, no more than once a year, except after a personal data breach affecting their data, when no such limit applies. Audits take place during business hours, must not unreasonably disrupt the service, and are subject to confidentiality. Each party bears its own costs.

TO FILL — no SOC 2, ISO 27001 or equivalent certification exists, and no independent penetration test has been carried out. Enterprise buyers will ask for one or more of these; the honest answer today is that they are not available.

9. Liability

Liability under this Agreement is subject to the limitations in the Terms of Service, except where Art. 82 GDPR or other mandatory law provides otherwise. Nothing here limits a data subject's rights against either party.

10. Term

This Agreement takes effect when the Customer starts using PageWard and continues until all Customer personal data has been deleted or returned in accordance with §7.

Annex I — Details of processing

Subject matterHosting self-contained HTML pages and serving them privately to viewers the Customer authorises.
DurationFor the term of the Customer's use of PageWard, plus the deletion period in §7.
Nature and purposeStorage, retrieval, transmission and display of Customer content; authentication of viewers; access control; recording of page views for the Customer's visibility.
Categories of data subjectsThe Customer's personnel who upload pages; people the Customer invites to view a page, who may include employees, clients, partners or other external parties; and any individuals whose personal data the Customer chooses to include inside an uploaded page.
Types of personal dataEmail addresses (uploaders and invited viewers); page titles, descriptions and filenames chosen by the Customer; view records (email address, page, timestamp); and any personal data the Customer places inside an uploaded HTML file, whose contents we do not inspect or control.
Special categoriesNone. Uploading Art. 9 or Art. 10 data is prohibited by the Acceptable Use Policy. PageWard is not designed or assessed for it.
FrequencyContinuous, for the duration of the service.

Annex II — Technical and organisational measures (Art. 32)

These describe what is actually implemented today. Where a measure a reviewer would expect is absent, it is listed as absent rather than omitted.

Access control and tenant isolation

  • Row-Level Security is the only authorisation boundary. Every query runs as the signed-in user. The application holds no service-role or admin database key, so a flaw in application code cannot escalate past the database's own policies.
  • Every artifact, allowlist entry and view record is scoped to an organisation identifier, and every policy filters on it.
  • Tenant isolation is verified by an automated test matrix, not by inspection — including a test that a user of one organisation cannot retrieve another organisation's stored file by requesting its storage path directly.
  • Files are held in a private bucket restricted to HTML and 10 MB, served only through an authenticated application route. No public or signed bucket URL is ever issued.

Isolation of untrusted content

  • Uploaded pages render in a sandboxed iframe without allow-same-origin, giving each page an opaque origin. Page scripts cannot read PageWard session cookies or reach another page.
  • The same restriction is applied a second time as a Content-Security-Policy sandbox header on the file-serving response, so it holds even if the URL is opened directly.
  • An automated regression test asserts that allow-same-origin is absent from every such surface, so the guarantee cannot be removed by an ordinary code change without the build failing.

Confidentiality and integrity

  • TLS in transit; encryption at rest by the hosting providers.
  • Authentication by emailed magic link, or a password the user sets. TO FILL — leaked-password checking against HaveIBeenPwned is available in the auth provider and is currently disabled; enable it.
  • Pause is enforced in the database, not only in application code: a paused page's bytes are refused even to an otherwise-authorised viewer requesting storage directly.
  • Access to a page is recorded, and the record cannot be suppressed by the viewer.

Availability and resilience

  • Managed hosting with provider-level redundancy.
  • TO FILLthe pilot currently runs on a hosting tier with no database backups. This must change before any paid customer, and the backup and point-in-time-recovery position must then be stated here concretely.
  • TO FILL — no documented restore test has been performed. A backup nobody has restored is a hypothesis.

Organisational measures

  • Data minimisation: we store the file, the allowlist and the view log. We do not inspect page contents, and we do not profile viewers.
  • Single operator. PageWard is run by one person, who has administrative access to the database. There is no second operator, no separation of duties, and TO FILL — no documented business continuity arrangement or named technical fallback. This is disclosed rather than glossed, because it is the first thing a procurement review will find.
  • TO FILL — confirm multi-factor authentication is enabled on every administrative account: hosting, database, domain registrar, email and payment provider.
  • Uploads are not scanned for malware or content.
  • No independent penetration test or security certification.

Annex III — Authorised sub-processors

Sub-processorPurposeLocation
SupabaseDatabase, authentication, file storageEU — eu-central-1, Frankfurt TO FILL — confirm contracting entity
VercelApplication hosting and serverless computeEU — functions pinned to fra1, Frankfurt. Edge middleware runs globally (see §5)
Email delivery providerSending sign-in linksTO FILL — confirm which provider is actually wired in, its contracting entity and its location
Payment providerSubscription billing and invoicingTO FILL — not yet engaged; add before charging
Domain / DNS providerDNS and marketing-site deliveryTO FILL — confirm whether any personal data is processed here; if not, remove this row

TO FILL — accept and retain each provider's own data processing agreement. These are normally click-through in the vendor dashboard; do it and keep the records, because a sub-processor without a DPA is a defect in ours.

Signature

Where a Customer requires a signed copy, request one from privacy@pageward.dev. DECIDE — whether to make this DPA self-executing by incorporation into the Terms (faster, standard for self-serve products) or to countersign per customer (slower, expected by some enterprise buyers).