DRAFT FOR COUNSEL REVIEW - not legal advice - counsel review is planned after launch
Lumioh Cloud Data Processing Agreement (draft)
Draft 0.2, updated 14 October 2026. See README.md for the placeholder list and the open legal questions.
This draft is written from 09 - security threat model, 10 - privacy and data governance, 32 - data inventory and erasure coverage, 30 - hosted dev environment, ADR-083 and ADR-088 in 21 - architecture decisions, and the decisions in 22 - open questions. It says what the system does, marks what is only planned, and leaves bracketed placeholders for facts only the owner can supply (the company's legal details and the backup period).
1. Parties, roles and scope
- This agreement is between the customer who uses Lumioh Cloud (the Customer: an agency or site owner that holds a workspace) and [COMPANY LEGAL NAME], ABN [ABN], of [REGISTERED ADDRESS] (Lumioh). It forms part of the Terms of Service.
- Customer site data is the information the Customer puts into Lumioh Cloud, or has the Connector, crawler or Search Console connection send to it, about the Customer's sites and clients (Annex 1). For customer site data the Customer is the controller (the party deciding the purposes and means) and Lumioh is the processor, acting on the Customer's behalf. If the Customer is itself acting for its own client, the Customer is the processor and Lumioh is its sub-processor, and the Customer must pass equivalent terms down to that client.
- For account, billing, security and product-operation data (the e-mail addresses and sign-in records of the people who use Lumioh Cloud, trial and payment records, audit and security logs, and product analytics) Lumioh is the controller, and the Privacy Policy applies, not this agreement. Counsel is asked to confirm the line for Client Viewer accounts that an agency creates for its clients, for member e-mail addresses in invitations, and for the workspace audit log.
- Privacy laws that may apply: the Privacy Act 1988 (Cth), the Australian Privacy Principles and the Notifiable Data Breaches scheme. If counsel decides GDPR or UK GDPR also apply, the terms in section 6 and section 8 will be extended. This draft uses "controller" and "processor" in the GDPR sense for clarity; the Australian Act uses different words.
2. Instructions
- Lumioh processes customer site data only on the Customer's documented instructions: these terms, the Terms of Service, the Customer's configuration of the product (which sites it connects, which scopes it approves, which Search Console properties it maps, which members and Client Viewers it adds), and its use of the product's features.
- Lumioh does not use customer site data for its own purposes, sell it, show advertising, use it to train AI models, or send it to an AI provider. Lumioh keeps internal counters (requests, bytes, durations) that contain no page addresses or personal information, and may process data where the law requires or to protect the security of the Service.
- Lumioh will tell the Customer if it believes an instruction breaches the law.
3. Confidentiality and personnel
Lumioh requires people with access to customer site data to keep it confidential. Production access is limited to a small number of people whom Lumioh authorises. A platform privacy operator role exists to review workspace deletion requests; an operator can approve a deletion for the Customer's own confirmation but cannot confirm it for the Customer. Only a platform operator can place or release a legal hold, through recorded actions. No production operators have been provisioned yet.
4. Security
Lumioh implements the measures in Annex 2, which are those in its security threat model, with the status of each stated. The Customer is responsible for the security of its own sites, accounts and the people it adds.
5. Sub-processing
- The Customer gives Lumioh a general authorisation to use the subprocessors in subprocessors-draft.md (Annex 3) and to change them as set out here.
- Lumioh will bind each subprocessor by contract to data protection obligations that give the same level of protection as this agreement, and remains responsible for it.
- Lumioh will give the Customer at least 30 days' notice of a new or replaced subprocessor that will receive customer site data, by e-mail to the Owner and by updating the list. The Customer may object on reasonable data protection grounds within that period. If the objection cannot be resolved, the Customer may stop using the affected feature or end its workspace.
6. International transfers
- Customer site data is stored by Supabase in Sydney, Australia, and processed by servers on Google Cloud in Sydney, Australia. Lumioh makes no regional-hosting promise beyond that statement.
- Some subprocessors (Resend, Stripe, Cloudflare, PostHog) and the providers' own operations may process limited data outside Australia; the regions are in the subprocessor list. Resend sees recipient e-mail addresses and message text (which can include the workspace and site names); Stripe sees billing contact and payment data; Cloudflare sees the IP address and browser signals of a person at sign-up, sign-in or password reset; PostHog sees product analytics events about account activity, with random identifiers and never the address or content of a customer's site. Detailed customer site data such as findings, crawl results and Search Console figures is not sent to those providers: a critical alert e-mail names the site and links to the alert inbox, and the daily digest names the workspace and gives counts.
- Before disclosing personal information outside Australia, Lumioh takes reasonable steps to make sure the recipient handles it in line with the Australian Privacy Principles, mainly through the recipient's data processing terms. If GDPR or UK GDPR apply, the mechanism for a transfer (such as standard contractual clauses and a transfer assessment) is for counsel to decide.
7. Helping with requests from individuals
- If an individual asks Lumioh about customer site data, Lumioh will refer them to the Customer, and will tell the Customer within 5 business days where it can.
- The Customer can fulfil most requests itself with the tools in Annex 4 (export, disconnect, delete a site, client or workspace). Lumioh will give reasonable help beyond those tools within 30 days. Ordinary requests are free; for a request that needs significant work, Lumioh may charge its reasonable costs after telling the Customer first.
- Erasure is not total. Lumioh does not claim that any erasure removes every trace; Annex 5 states what remains.
8. Personal data breach
- If Lumioh becomes aware of a breach of security leading to the loss, unauthorised access to or disclosure of customer site data, it will start a documented assessment at once and make a first assessment within 72 hours of becoming aware. It will tell the Customer's Owner as soon as practicable after that first assessment, and never later than 30 days after becoming aware, and will give what it knows: what happened, the data and customers affected, likely consequences, and what is being done. It will update the Customer as it learns more.
- Where the breach is likely to result in serious harm, Lumioh will also notify the Office of the Australian Information Commissioner as the Notifiable Data Breaches scheme requires. Customers are told by e-mail from the transactional sender and, once built, by an in-product notice.
- If GDPR or UK GDPR apply to the Customer, a 72-hour clock for notifying a regulator may run from when the Customer becomes aware, and the Customer may need Lumioh to notify it sooner. Counsel is asked to decide whether the first assessment time in 8.1 is enough.
- The Customer is responsible for deciding whether to notify its own regulators and individuals.
9. Assessments and audits
Lumioh will give the Customer the information needed to show compliance with this agreement: this agreement and Annex 2, the workspace audit log (readable by the Customer's Owner and Admins), the export of deletion-request history, and a completed security questionnaire once a year. Lumioh will share a summary of any independent security review when one exists (a penetration test is planned after launch). If the Customer reasonably needs more, because a regulator requires it or after a confirmed breach, Lumioh will allow a remote audit on 30 days' notice, during business hours, at the Customer's cost, no more than once a year, under confidentiality, and without access to other customers' data. The Customer can also see who in its workspace did what in its audit log.
10. Return and deletion at the end
- During the term the Customer can export its data and delete sites, clients, the workspace and (for its own account) the account (Annex 4).
- When access ends (trial end, cancellation or non-payment) paid work stops and the workspace is read-only for 30 days for reading, export and privacy requests. After that, product access stops except the Owner's privacy and deletion request. Lumioh keeps the locked workspace for up to 12 months after the 30 days end, then deletes it through the confirmed workspace erasure process after giving the Owner at least 30 days' notice. The Customer can instruct deletion, or restore access by paying, at any time before that.
- On instruction (or at the scheduled time), Lumioh deletes the workspace through the confirmed workspace erasure process, subject to Annex 5. Lumioh aims to complete a confirmed erasure within 30 days. Lumioh will confirm in writing on request that the erasure request was completed; it will not certify that all copies are gone.
- Lumioh may retain data as the law requires, and under a legal hold. A legal hold is placed only by a platform operator, recorded in the audit trail, and may not be disclosed to the workspace.
11. Customer obligations
The Customer must: have a lawful basis and authority to connect each site and give Lumioh the data; give notices and obtain consents required from its clients, site owners and visitors; connect only sites it controls; not submit special categories of personal information on purpose (the product is not designed for it, and does not take post bodies); keep its members and Client Viewers up to date; and give lawful instructions.
12. Liability, term and governing law
The limits and exclusions in the Terms of Service (section 18) apply to this agreement. This agreement lasts as long as Lumioh processes customer site data for the Customer, and the retention periods in Annex 5 continue after. If this agreement conflicts with the Terms of Service on data processing, this agreement applies. Governing law: the law of [GOVERNING LAW STATE], Australia, and the courts of that State and the Commonwealth courts sitting in it.
Annex 1 - Details of the processing
| Item | Detail |
|---|---|
| Subject matter | Providing Lumioh Cloud: a central view of the health, changes and search performance of the Customer's WordPress sites, with crawling, Search Console ingestion, alerts and reports |
| Duration | For as long as the Customer's workspace exists, plus the periods in Annex 5 |
| Nature | Receiving from the Connector, crawling public pages, reading Search Console data, storing, analysing, displaying, reporting, alerting by e-mail, exporting, deleting |
| Purpose | To provide the Service to the Customer under the Terms of Service |
| Where | Sydney, Australia (database, storage, servers); see section 6 |
Categories of customer site data
| Category | What it contains | Personal information? |
|---|---|---|
| Site and client records | Site name and URL, WordPress, plugin and PHP versions; client names; the Customer's free text (client contact lines, alert mute reasons, report template names, indexability notes of up to 200 characters) | Possibly: a site address or name can identify a person (a sole trader); free text can hold anything |
| Connector data (only scopes the site administrator approves) | Heartbeats; audit findings (key, severity, status, check ID, reference to the affected item, plugin-supplied description fields); summaries of SEO changes (allowlisted metadata, settings and migration events); a summary of 17 on/off settings with a fingerprint; redirect and link-graph summaries | Incidental: item references and descriptions may include names or addresses. No post bodies, database content, credentials or arbitrary options are sent |
| Crawl observations | For each public page: address, HTTP status, redirect path, canonical address, content type, title, meta description, robots directives, hreflang, structured-data types; normalised robots.txt rules. No HTML or body is stored | Incidental: titles and addresses of public pages can contain names |
| Search Console data | Daily clicks and impressions per property; for connected sites top 50 page or search query rows per date, kept 120 days | Possibly: page addresses and search query text can contain personal data |
| Agency branding and reports | Display name, contact line, colours, logo; reports built from the data above | Possibly (contact line, logo) |
| People data held for the Customer | Client Viewer accounts the Customer creates (e-mail address, assigned clients and sites); assignment of Technicians to sites | Yes. Counsel is asked to confirm whether this is customer site data or Lumioh-controlled account data |
| Alerts | Alert rules, history and delivery details (payload-free delivery metadata 90 days) | Recipient is an account |
| Audit log | Actor, action, item, time, request number for sensitive actions in the workspace | Yes (actor identifiers; e-mail addresses are scrubbed on account erasure) |
| Secrets | A random credential created at pairing and the Google refresh token, stored encrypted | Not about a person, but treated as secret |
Categories of data subjects
- The Customer's staff, contractors and members (Owners, Admins, SEO Managers, Technicians, Reporters).
- The Customer's clients and their staff (Client Viewers, named contacts).
- Individuals who can be identified from a site address, a page address, title or search query: authors, people named on pages, and people who search.
Special categories
None are intended. The Customer must not put sensitive information in free-text fields. Search queries or page addresses could contain it; the Customer is responsible for its sites' content.
Annex 2 - Security measures
"In place" means built and tested with synthetic data in local or isolated environments. The hosted production environment is created after this draft, so hosted acceptance with real customer data has not happened. See doc 09 for the controls and doc 32 for gaps.
| Area | Measure | Status |
|---|---|---|
| Tenant isolation | Every tenant table is scoped by workspace with row-level security policies read once per statement (ADR-078); opaque identifiers; a coverage suite fails if a callable function or table is not classified; cross-tenant tests | In place; tested locally |
| Access control | Six roles (Owner, Admin, SEO Manager, Technician, Reporter, Client Viewer); Client Viewers see assigned items only; invitations bind to the exact verified e-mail; ownership transfer requires an Admin's acceptance; reports are built per role | In place |
| Product write guard | After access ends, every write is refused by database guards except confirmed erasure and the Owner's privacy request | In place locally; hosted acceptance open |
| Authentication | E-mail and password via a managed sign-in service with a verified e-mail; Cloudflare Turnstile on sign-up, sign-in and password reset; session cookies Secure in production and SameSite=Lax; MFA is optional (not required in the beta); limits on pairing codes | In place; the owner reported the Turnstile forms working in browser checks on 14 October 2026; shared per-address sign-in limits are open |
| Connector authentication | A random 256-bit secret per site, request signing with replay checks, pairing codes that are hashed, bound to state and PKCE, valid 10 minutes, rate-limited; revocation | In place |
| Encryption in transit | HTTPS only in hosted environments; Content-Security-Policy, frame protection and other security headers | In place; browser soak on hosted open |
| Encryption of secrets at rest | Site credentials and Google tokens encrypted with AES-256-GCM and bound to the connection or workspace; hosted use encrypts keys with Google Cloud KMS (software protection, keys rotated every 90 days); revoked secrets deleted | Adapter in place; hosted KMS acceptance (Q15) open |
| Disk and database encryption at rest | Provided by Supabase and Google Cloud under their own terms | Not independently verified by Lumioh; to be confirmed from the providers' documents |
| Private storage | Report PDFs and brand logos live in private buckets with no public policy; PDFs expire in about 24 hours; logos are validated (PNG or JPEG, 256 KiB, metadata stripped) | In place |
| Network | Only the web service is public; the PDF renderer and crawler fetcher are internal and IAM-restricted; the renderer has no network access; the crawler runs in its own subnet with a firewall that blocks private and reserved ranges and a fixed outgoing address; no long-lived service-account keys | Defined in infrastructure code and deployed to the development project |
| Crawler safety | Public HTTP and HTTPS only; DNS and address checks on every request and redirect; size, time and redirect limits; robots.txt honoured; no HTML kept | In place; hosted acceptance open |
| Secrets management | Secrets in Secret Manager, separate per environment, none in source or the browser; redaction in logs; a dedicated database key for each hosted job | Partly in place; rotation of the database password and of shared and earlier keys is scheduled for after launch (C5) |
| Logging and audit | Audit log of sensitive actions without secrets; application logs carry opaque identifiers only, with per-emitter allow-lists; no names, e-mail addresses, URLs, tokens or payloads | In place; hosted logging and its 30-day retention not provisioned |
| Data minimisation | No HTML retention; scope consent per site; allowlisted fields; only the permitted fields from the legacy audit path | In place |
| Backups and recovery | Not switched on at launch. Database backups and point-in-time recovery are deferred until there are 10 paying users (C1). Once on, the aim is 24 hours of data loss at most and restore within 8 hours; erasure is not replayed automatically after a restore | No backups and no recovery guarantee until then; retention [BACKUP RETENTION]; a restore drill is proven locally only |
| Vulnerability management | Dependency and secret scanning, static analysis, an SSRF test corpus, a tenant-isolation suite and other gates are listed as required before production; an independent penetration test is planned after launch (D8) | Not all met; check before relying on this row |
| Incident response | Fifteen operational runbooks; severity model adopted 14 October 2026 (S1 acknowledge within 1 hour, S2 next business day, S3 within 5 days); on-call is the owner, best effort | Adopted as targets; there is no backup person |
| Personnel | Confidentiality for people with production access | Written policy, training and access reviews are not yet in place |
Annex 3 - Subprocessors
See subprocessors-draft.md: Supabase (database, sign-in, storage; Sydney), Google Cloud (servers, keys, secrets; Sydney), Resend (e-mail), Stripe (payments), Cloudflare (Turnstile bot check, and DNS only, with no customer data) and PostHog (product analytics of account activity, never customer site data). Google Search Console is a data source the Customer authorises, not a subprocessor.
Annex 4 - Helping with requests: the tools that exist
| Request | What the Customer can do | Notes |
|---|---|---|
| Copy of data (access, portability) | An active Owner or Admin downloads a JSON export of one site or the whole workspace | Excludes connector credentials, raw site event payloads, raw provider messages and account e-mail addresses; limited to 16 MiB; each export is recorded in the audit log; available while access is active and for 30 days after it ends |
| Correction | Edit records in the product; fix source data on the WordPress site | Plugin data is corrected at the source |
| Stop collection or object | Revoke a scope; disconnect a site; pause or cancel crawls; disconnect Search Console (token deleted, the Customer chooses whether to delete the stored figures) | Already-received data stays until deleted |
| Delete a site | An Owner or Admin requests with an explicit confirmation; a worker deletes the site and everything under it | Asynchronous, with visible state |
| Delete a client | The Owner types the client's name; a worker deletes the client and its sites | |
| Delete the workspace | The Owner requests; a Lumioh operator reviews and approves; the Owner types the workspace name; a worker erases in bounded steps. Blocked while a paid subscription is live or a legal hold applies | Never automatic while access is active |
| Delete a person's account | The person requests in Settings, Privacy, confirms with the exact address after a fresh sign-in, and waits seven days (cancellable). Refused while they are a workspace's only Owner | Built and tested locally; not enabled on a hosted environment yet |
| Individual's request to Lumioh | Lumioh refers it to the Customer | Section 7 |
Annex 5 - Return and deletion: what happens and what remains
| Item | Treatment | Note |
|---|---|---|
| Workspace after access ends | 30 days read, export and privacy request; then no product access except the Owner's privacy request; the locked workspace is kept for up to 12 months and then deleted after 30 days' notice to the Owner | Done by Lumioh by hand; no automatic job yet |
| Site, client and workspace erasure | The rows listed in Annex 4 are deleted; the Google token is revoked at Google first on a best-effort basis; brand logo files are removed before the first erasure step | Local and synthetic evidence only; the deletion worker cannot run in the hosted environment yet |
| Deletion tombstone | A request number, an opaque workspace reference and timestamps, kept 24 months and then purged, unless under a legal hold | Names, addresses and account identifiers are not kept on a completed record |
| Audit-log rows naming an erased site or client | The row remains; the identifiers are removed 24 months after the audit row was written | Policy built in the maintenance job; not deployed to hosted |
| Account identifiers in history | Cleared or replaced with a one-way random reference; the audit log's actor, identifier and e-mail text are scrubbed | Built, with the account deletion worker and page |
| Trial marker | A salted hash of the verified e-mail, 24 months | Q72, Q93 |
| Application logs | Not purged on erasure; 30 days | Hosted logging not provisioned (R4) |
| Backups and point-in-time recovery | Not switched on at launch. Once on, not purged on erasure, kept as the chosen Supabase plan provides, [BACKUP RETENTION]; a restore could resurrect erased data; an expedited re-erasure is decided (Q71) but not built | R3 |
| Product analytics events | Random identifiers only; kept 13 months at PostHog | Deleted through PostHog on erasure once that is built (E5); until then they remain |
| Report PDFs | Removed by a cleanup job within about 24 hours | Up to 24 hours after erasure |
| E-mail provider, Stripe, Google | Their copies are not deleted by Lumioh; Stripe invoices and tax records follow the law | R6 to R8 |
| Customer-held | The WordPress site and the Connector, downloaded exports | Out of Lumioh's reach |
| Retention of site data | 36 months standard or 60 months Pro or Agency (Search Console figures, events, crawl results, findings and snapshots); page and query rows 120 days; heartbeat detail 90 days; other periods are in the Privacy Policy, section 10 | Plugin events, Search Console figures and the operational records have a clean-up job; crawl results, findings, snapshots and heartbeat detail are policy only (R5) |
Facts to verify with counsel
- The roles in section 1 (README question 1), including Client Viewer accounts and the workspace audit log, and the position if the Customer is itself a processor.
- Which law applies: the Privacy Act and the Australian Privacy Principles (including APP 8 for the offshore providers), and whether GDPR or UK GDPR and standard contractual clauses are needed (README questions 2 and 3).
- The breach notification wording in section 8 (README question 4): a 72-hour first assessment and a 30-day outer limit for telling the Customer, and whether a customer subject to GDPR needs a shorter notice.
- The 30 days' notice and objection mechanism for subprocessors (section 5.3), and whether a general authorisation is acceptable.
- The statements about erasure in Annex 5 (README question 6), including whether site and client tombstones may go with an erased workspace (Q70) and legal holds (Q94).
- The audit terms (section 9) and the cost of assistance (section 7.2).
- The security statements in Annex 2: each "In place" row should be checked against the product before the DPA is signed, and the provider at-rest encryption rows completed from the providers' documents.
- Whether Google Search Console data brings additional obligations under Google's API Services User Data Policy (README question 10).
- Whether keeping a locked workspace for up to 12 months and then deleting it after notice (section 10.2) is acceptable as the end-of-term position (README question 7).
- Whether the processor terms of each subprocessor (Supabase, Google Cloud, Resend, Stripe, Cloudflare, PostHog) give the protection that sections 5.2 and 6.3 promise.
Facts this draft assumes that the code may not yet implement
- Hosted deletion. Workspace and client erasure are built and tested only with synthetic data in a local stack; the worker flag is off by default and the worker refuses to run in hosted environments (ADR-083). Hosted scheduling and enablement (E7) are not done.
- Account erasure (ADR-088, ADR-096) has a worker, a Settings page, notices to the account and to co-owners, and an operator requeue; it is tested locally and is not enabled on a hosted environment. Provider-side deletion at Stripe, Google and Resend (E5) is not done.
- Retention. The maintenance job (plugin events, terminal alert queue rows, pairing codes, tombstones, ownership-transfer records, trial markers, audit-row identifiers, command payloads) and the worker purges (Search Console, delivery records, notices) are built and tested locally; the maintenance job and its migration are not deployed to hosted. Crawl results, findings, snapshots, heartbeat detail and event batch receipts have no job yet, and no job deletes a locked workspace after 12 months. Hosted logging and backups are not provisioned.
- Re-erasure after restore (Q71) is a decision, not a mechanism, and depends on a hosted restore drill. There are no backups at launch (C1).
- Security statuses. KMS-encrypted credentials, the Content-Security-Policy, Turnstile, per-job keys and key rotation are in various stages (Annex 2). The "before production" security gates in doc 09 section 7 are not all met, and the penetration test is deferred (D8).
- Breach process. The severity model is adopted as targets; the on-call rota is the owner with no backup person. Customer communications are by e-mail only.
- Operator access. No production privacy operator has been provisioned; no production access policy has been written.
- Subprocessor notice. No mechanism exists to notify customers of subprocessor changes other than by hand.
- PostHog is not in the product code. The statements about what it receives are commitments the implementation must meet before analytics is switched on.
- Export window. Export links disappear after the 30-day window; the Owner's privacy request remains. There is no built path for a controller to obtain a copy of data after the window other than asking Lumioh.
- Public API and webhooks (ADR-089) are proposed only. If built, API keys, webhook destinations and delivery logs become processed data, and a customer-chosen webhook receiver is outside Lumioh's control.
- Google token revocation on erasure (Q58) is built in source but not verified against Google's real responses or the hosted key permissions.