Fiskwise Privacy Policy

Last updated: 2026-09-01 · Version 2026-09-01.1

1. About this policy

1.1 This policy explains what personal data Fiskwise collects, why we collect it, who we share it with, how long we keep it, and what you can ask us to do about it.

1.2 Fiskwise is operated by [ENTITY] of [ADDRESS] ("Fiskwise", "we", "us"). We run the accounting and business-operations platform at https://fiskwise.com.

1.3 We have written this to be read. Where the honest answer is uncomfortable, particularly about deletion in section 9, we have said so rather than promising something the software does not do.

1.4 Two roles, and which one applies

Fiskwise handles personal data in two different capacities, and your rights depend on which applies.

If you are an individual whose details appear in someone's Fiskwise books, because you are their customer or their supplier, we are not the controller of that data. Please contact the business that holds the records. If you contact us instead, we will pass your request on to them where we can identify them, and we will tell you that we have done so.

1.5 The Terms of Service, the Refund and Cancellation Policy and the Subprocessor List sit alongside this policy.

2. The short version

• We collect what we need to run an accounting system for you, bill you for it, and keep it secure.
• We set no advertising or analytics cookies. There is no Google Analytics, no tag manager, no product-analytics SDK, no session replay, no advertising pixel, and no third-party error-tracking service anywhere in the product. See section 7.
• We do not sell personal data, and we do not share it for cross-context behavioural advertising.
• We do not use your data to train AI models.
• We use a small number of named subprocessors, listed in section 8, each for a specific job.
• Deletion is a request you make. We action it with an automated purge engine within a 30-day response commitment, and issue a verifiable completion certificate. Section 9 explains exactly what that means.

3. What we collect

3.1 Account and identity data

Collected when an account is created or a user is invited.

• Name, email address, and whether the email has been verified.
• A password, stored only as a cryptographic hash, we never store or see the password itself.
• Profile image URL, if set.
• Two-factor authentication state: whether it is enabled, the TOTP secret, and backup codes.
• Session records: a session token, the IP address and the browser user-agent string captured when the session was created, and the session's creation, update and expiry times.
• If a social or OAuth sign-in method is ever enabled, the linked provider account identifier and the tokens for it. (No social sign-in provider is enabled today.)
• Invitation records: the email address invited, who invited them, the role offered, and whether the invitation was accepted.
• Consent evidence: which legal document you accepted, at which version, when, how (self-service, by invitation, or recorded by an operator), and the IP address and user-agent at the moment of acceptance.

3.2 Workspace and configuration data

The organisation and company records you create, fiscal calendars, chart of accounts, roles and permissions, per-user dashboard layouts, appearance preferences, onboarding progress, numbering settings, and the modules you have turned on.

3.3 Your business records: the books

This is the bulk of what we store, and most of it is yours rather than ours (see section 1.4). It includes:

• Customer and supplier records: display and legal names, contacts (first name, last name, full name, email address, telephone number), postal addresses, tax registration details, credit terms and credit limits, and, for suppliers, a federal or national tax identification number where you enter one.
• Transactions: journal entries and lines, sales quotes, invoices, credit notes, customer payments and applications, supplier bills, credit notes and payments, statements, disputes, promises to pay, collections and dunning history, and write-offs.
• Operations data, depending on the modules you use: items, prices, inventory lots and serial numbers, stock movements, locations and bins, purchase orders, goods receipts, sales orders, shipments, work orders, routings, time tickets, quality inspections, non-conformances, warranty claims, fixed assets and depreciation books, budgets and forecasts.
• Free-text fields: descriptions, notes, memos, internal comments, which may contain whatever your users type into them, including personal data.

3.4 Banking data

• Bank account records: the account name, the institution name, the account type and currency, and a masked account number. We do not store full bank account numbers in this record.
• Statement lines, whether imported from a file or received from a bank data feed: the posted and value dates, the amount and currency, the transaction description, the counterparty name, and the bank's own reference and identifiers. Bank descriptions routinely contain personal names.
• Bank feed connections, where you connect an account through our bank data provider: the institution identity, the accounts linked, the sync state and cursor, and error records.
• The bank aggregator access token, which authorises us to read your feed. It is stored encrypted at rest as an AES-256-GCM ciphertext under a dedicated key held outside the database (BANK_FEED_ENCRYPTION_SECRET), with the key version recorded so keys can be rotated.
• Raw webhook payloads received from the bank data provider, retained as delivered.

3.5 Payment data

• Platform billing: what you pay us: your billing contact name and email, the billing address where collected, the subscription and plan, invoices and lines, charges, credits, refunds, and a token identifying your payment method at our payment processor together with display metadata such as the card brand and last four digits.
• Customer payments: what your own customers pay you, if you use the hosted payment feature: payment intents and their status, amounts, refunds, disputes, payouts, the payment processor's identifiers for your customers, and saved-method tokens.
• We never receive, store, transmit or log full card numbers. Card details are entered directly into the payment processor's own hosted fields, which run in an iframe served by the processor. The card number never reaches our servers or our database.
• Supplier payment credentials: where you store instructions for paying a supplier, are encrypted at rest as a single AES-256-GCM blob under a separate dedicated key (PAYMENT_CREDENTIAL_ENCRYPTION_SECRET). No endpoint returns them; they are decrypted in memory only at the moment of use.
• Raw webhook payloads received from the payment processor, retained as delivered.

3.6 Documents and attachments

Rendered documents, invoices, quotes, statements and similar, are generated as PDFs and the bytes are stored in the database, together with a hash and size. Document templates, branding assets, and the metadata of every rendered document are stored alongside them.

3.7 Communications we send on your behalf and to you

For every outbound message: the recipient email addresses, the subject, the message body, the attachment sent, the provider's message identifier, and the delivery state, queued, sent, delivered, opened, bounced or failed, with the timestamp for each. See section 7.4 on email tracking.

3.8 The audit trail

Fiskwise keeps two layers of audit record. This matters for your rights, so it is worth being precise.

• `audit_events`, the business audit log. One row per recorded action: who did it (user identifier and label, or an API key, or the system), what they did, which record it affected, a human-readable summary, structured metadata, and when.
• `row_change_log`, the forensic log. Written automatically by database triggers on roughly 250 of the service's approximately 300 tenant tables. Each row stores the complete before-image and after-image of the changed database row as JSON.

The practical consequence: if a field contained personal data and was later edited or deleted, the old value still exists in the forensic log. Correcting a supplier's tax identification number, for example, does not remove the previous value from row_change_log. Some tables are deliberately excluded from the forensic log, the encrypted credential and token vaults, the document blob bytes, and high-churn machine-state tables, so secret material never enters it. Business records are not excluded.

3.9 API keys, webhooks and integrations

API keys you create (stored as a hash, never in plain text), the endpoints you register for outbound webhooks and their delivery history, and the connections and OAuth tokens for any third-party integration you set up. Integration tokens are encrypted at rest under a dedicated key (INTEGRATION_TOKEN_ENCRYPTION_SECRET).

3.10 Technical and log data

Server logs generated in the ordinary course of running the service, containing request paths, error messages, timing and similar operational information. IP addresses and user-agent strings are stored against sessions and against consent records as described above. We do not currently use a third-party error-tracking or application-monitoring vendor; logs stay with our hosting provider.

3.11 What we do not collect

We do not ask for, and the product has no field for: government identity documents, biometric data, health data, or data about racial or ethnic origin, political opinions, religious beliefs, trade union membership, sex life or sexual orientation. We do not collect precise geolocation. We do not buy personal data from data brokers. We do not build advertising profiles.

Note that a supplier's tax identification number (section 3.3) is a national identifier and, for a sole trader, may be a personal one. It is stored because tax reporting requires it. It is not encrypted at field level, and it is included in the forensic log described in section 3.8.

4. Why we use it, and our legal basis

Where data protection law of the UK, EEA or a similar regime applies, these are our bases.

4.11 Where we rely on legitimate interests, we have considered the impact on you and concluded our interest is not overridden. You may object; see section 10.5.

4.12 Where we act as processor (section 1.4), we act on the customer's instructions and the customer is responsible for the legal basis.

5. Who we share it with

5.1 Subprocessors, the service providers we use to run Fiskwise. Listed in section 8 and in the separate Subprocessor List.

5.2 Recipients you direct. When you send an invoice, we send it to the address you specify. When you connect an integration or register a webhook endpoint, data goes where you have told it to go. When your customer pays through the hosted payment page, their details go to the payment processor.

5.3 Professional advisers, our lawyers, accountants and auditors, under confidentiality.

5.4 Legal and regulatory. We may disclose data where we are legally required to, or to establish, exercise or defend legal claims. We will tell you about a request for your data unless we are legally barred from doing so.

5.5 Corporate transactions. If we are involved in a merger, acquisition, financing or sale of assets, data may transfer as part of it. You will be told, and this policy will continue to apply until replaced by one that is at least as protective.

5.6 We do not sell personal data, and we do not share it for cross-context behavioural advertising or targeted advertising. We have never done so.

6. AI processing

6.1 The AI features are off by default, twice over. They do nothing unless an AI provider is configured on the deployment and you have enabled the AI policy for your workspace, and they are gated on an entitlement attached to your plan.

6.2 The only AI feature today assists with bank reconciliation: proposing which existing ledger entry an unmatched bank line might correspond to.

6.3 What is sent. For each bank line and each candidate match, we send:

• a redacted transaction descriptor,
• the signed amount,
• the posted date, and
• an internal identifier and a ranking score.

No account holder name field, no email, no telephone number, no address, no account number, no document, and no attachment is sent. No customer or supplier master record is sent.

6.4 What the redaction actually removes, and what it does not. Before a descriptor leaves our servers, we strip and replace: email addresses; telephone numbers; runs of seven or more digits (which covers card numbers, account numbers and ACH trace numbers); and ACH or authorisation codes.

The redaction is pattern-based. It does not remove personal names. A bank descriptor such as a peer-to-peer transfer that includes an individual's name will retain that name. Amounts and dates are not redacted. We would rather tell you this than claim the prompt contains no personal data.

6.5 Training and retention. We instruct the AI provider not to retain the request and not to use it for training, by sending a no-retention request header on every call. We should be clear about the limit of that: it is a request made at the API layer, and whether it is honoured depends on the provider's terms and the account tier we hold with them. It is not a technical guarantee we can enforce from our side. Section 8 records the provider.

6.6 AI output is a suggestion, not a decision. Nothing is posted to your ledger by an AI suggestion alone unless you have configured automatic acceptance for it.

6.7 Automated decision-making. We do not carry out automated decision-making that produces legal effects concerning you or similarly significantly affects you. Two features apply rules automatically, and both are configured by the customer, not by us: automatic acceptance of a reconciliation match, and the credit hold that can block an order when a customer exceeds a credit limit the customer set. Both can be reviewed and overridden by a human within the app.

7. Cookies, storage and tracking

7.1 What we set, and nothing else

Fiskwise sets only strictly-necessary cookies. There is no advertising cookie, no analytics cookie, and no cross-site tracking cookie set by Fiskwise. Because of that we do not show a cookie-consent banner for our own cookies, there is nothing to consent to beyond what is necessary to sign you in and remember which workspace you are looking at.

7.2 Browser storage

We also keep a few preferences in your browser's own storage, which never leaves your device unless you send it to us:

• Local storage: your light/dark theme choice, and whether the secondary sidebar is collapsed.
• Session storage, cleared when you close the tab: an identifier for an in-progress signup so a refresh resumes it; an in-flight bank-connection token during the bank-link redirect; a dismissal flag for an in-app banner; and, on the developer docs console, an API key you have pasted there, deliberately in session storage rather than local storage, so it does not persist.

7.3 Third-party cookies you may pick up from features you use

We do not set these; the provider does, in its own frame, and only on the specific pages where you use that feature.

• The payment processor sets fraud-prevention cookies (a long-lived device identifier and a short-lived session identifier) when a card form is displayed. This happens on the billing page and, if a card is required for your plan, in the signup flow.
• The bank data provider sets its own cookies inside its connection widget when you open the bank-link flow.

7.4 Email delivery and open tracking

Emails we send through our email provider report back their delivery state. Our records include whether a message was delivered, opened, or bounced, and when. Open detection normally works by embedding a small invisible image in the message, which loads when the message is displayed.

This applies both to emails we send you and to emails you send your customers through Fiskwise. If you send documents to your customers through Fiskwise, you should tell them that delivery and open status is recorded. Whether open tracking is on is a setting in our email provider's console; ask us at [DPO/CONTACT] if you need the current position confirmed in writing.

7.5 Fonts and third-party scripts

The interface font is bundled with the application at build time and served from our own domain, your browser makes no request to a font host. The only third-party scripts the application loads are the payment processor's script, when a card form is shown, and the bank data provider's connection widget, when you open it. Neither is loaded on the marketing site or on ordinary application pages.

7.6 Do Not Track and Global Privacy Control

Because we do no tracking and no sale or sharing of personal data, there is nothing for a Do Not Track or Global Privacy Control signal to switch off. We honour them by default, by not doing the thing in the first place.

8. Subprocessors

These are the third parties that process data on our behalf. The separate Subprocessor List carries the same table plus our change-notification commitment.

8.2 Features you connect yourself are not our subprocessors. If you connect an e-commerce store, a messaging tool, a code host, a spreadsheet service, a currency-rate feed, or your own webhook endpoint, you are directing us to send data there. Those providers act for you, not for us, and their handling is governed by your agreement with them.

8.3 Data processing agreements. We are responsible for putting appropriate data-processing terms in place with each subprocessor. [TO COUNSEL: the executed DPAs with each of the above must be collected, and this sentence replaced with a confirmation that they are in place. Do not publish an assertion that they exist until they have been checked one by one.]

9. How long we keep data: read this carefully

This is the section where it is easiest to write a comfortable sentence that is not true. We have tried not to.

9.1 What the system does automatically today

Almost nothing. Specifically:

• The tenant purge engine runs only when an Owner files a deletion request and the withdrawal window expires. Nothing in the service deletes a workspace's data on a schedule, at the end of a subscription, or at any other automatic trigger.
• There is no retention sweep on the audit trail while a workspace exists. Neither audit_events nor row_change_log is trimmed, aged out, or archived during the life of the workspace. When a deletion request is actioned, the purge engine erases the workspace's audit trail along with all other tenant data (see section 9.4).
• Export bundles expire and are then erased. When you generate an export, the download link stops working after 30 days. An automatic sweep then deletes the bundle's stored bytes 7 days after the link expires; the export's history entry and its coverage manifest are kept.
• The other automatic clean-ups that exist are narrow and operational: settled records in the integration-sync staging area are removed after their retention window, expired rate-limit counters are swept, and expired sessions and verification tokens lapse.

9.2 What we keep while you are a customer

While your subscription is active, we keep your data for as long as your workspace exists, because that is the product: an accounting ledger you can go back through. You can delete individual records inside the application where the accounting rules allow it, but note that a posted ledger entry is generally reversed rather than erased, that is a deliberate property of double-entry bookkeeping, not a limitation we could remove.

9.3 What happens when you leave

• Your subscription ends, and access is blocked except for the billing, account and export paths.
• Your data remains in our database. It is not automatically deleted after 30 days, or after any other period.
• To have it deleted, you must ask. See 9.4.

9.4 Deletion is a request, and the purge engine executes it

An Owner of the workspace can file a deletion request from within the application. When you do:

1. The request is recorded with the requester's identity, the reason if you give one, and the time.
2. A response deadline is set at 30 days from the request, which is our commitment and reflects the one-month response period under data protection law.
3. We send an acknowledgement.
4. A withdrawal window begins. Until we begin actioning the request, the Owner who filed it can withdraw it from Settings.
5. The automated purge engine executes the deletion: it erases all tenant data from the application database (ledger, documents, master data, audit trail, files, integration state) and records the outcome.
6. A completion certificate is issued (see section 9.5).

There is at most one open request per workspace at a time, so a second Owner clicking the button joins the existing request rather than restarting the clock. The record of the request itself is kept permanently and deliberately, because it is the evidence that you asked and that we acted.

9.5 The purge certificate

When the purge engine completes, it produces a completion certificate containing: the tenant identifier, the timestamp of the request and of the purge, aggregate row counts per table, a list of any tables exempted and why (see section 9.6), and whether the purge completed in full or partially. The certificate is stored permanently as part of the deletion-request record; it does not contain any of your business data.

9.6 What we keep even after a deletion request, and why

Some records are retained after an erasure, either because the law requires it or because deleting them would destroy the evidence that we did what you asked:

9.7 An accounting system has genuine retention obligations

This is worth stating openly rather than treating retention as pure inconvenience. Businesses are generally required to keep accounting records, invoices, ledgers, supporting documents, for a number of years, and to be able to produce them to a tax authority or an auditor. An immediate, unconditional erasure on demand would defeat the purpose of the tool and could put you in breach of your own obligations. Where a deletion request conflicts with a retention obligation, the obligation generally prevails, and we will tell you which records that applies to.

9.8 Improvements we intend to make

The automated purge engine and completion certificate now exist (sections 9.4 and 9.5), and automatic clean-up of expired export bundles has been in place since section 9.1. We will continue to improve audit-trail retention controls and data lifecycle tooling, and we will update this policy and its version string when material changes ship.

10. Your rights

Subject to the law that applies to you, and to section 1.4 on which role we are playing:

10.1 Access

Ask what personal data we hold about you and get a copy. Most of it is already visible to you in the application.

10.2 Correction

Ask us to correct data that is wrong. Most fields are editable directly in the application, and that is the fastest route. Note section 3.8: correcting a field does not erase the previous value from the forensic log.

10.3 Deletion

Ask us to delete your data, subject to section 9. The mechanism is:

• For a whole workspace: an Owner files a deletion request in the application, under Settings, then Billing. We respond within 30 days.
• For an individual user account: email [DPO/CONTACT]. We erase the user account itself; what that removes, scrubs and keeps is set out immediately below.
• For a person whose details appear in a customer's books: contact that business, not us, see section 1.4.

What erasing a user account deletes. The user record and everything that hangs off it: the sign-in credentials, every active session, any linked sign-in provider, the two-factor enrolment, the saved dashboard layouts and the dismissed prompts. Membership of every workspace is removed, together with any approval-step assignment that named the person. Every invitation addressed to that email address is deleted, whether it was accepted or still pending. Workflow notifications addressed to the person are deleted.

What is scrubbed rather than deleted. Names and display labels are removed from audit records, and the forensic change images that carried the address are rewritten to read [erased]. The opaque internal identifier on those records stays. It no longer resolves to a person, and keeping it is what preserves the integrity of the audit trail, which is section 4.5's legitimate interest.

What is retained, and why. The entries the person posted stay in the ledger: the books record who did what, and removing that would destroy the accounting record itself (section 9.7). We keep an erasure certificate, described in section 9.6: counts, timestamps and a hash of the address, never the address itself, so we can prove the erasure ran without keeping the identity it removed.

One case we have to refuse. If you are the only Owner of a workspace that is still active, we cannot erase your user account while that remains true, because it would leave the workspace with nobody able to administer it. Invite another Owner and hand the workspace over, or file a deletion request for the workspace itself, and then ask us again. A workspace you have already cancelled does not block anything.

A user-account erasure request is answered within 30 days, on the same terms as every other request in this section (see section 10.8).

10.4 Portability: how to actually get your data out

Three routes, all available to you without asking us:

1. CSV exports from the reports and lists in the application, trial balance, profit and loss, balance sheet, cash flow, consolidated statements, budgets, and the various operational lists. These are the practical route for accounting data and they carry the detail you need.
2. The HTTP API, using an API key you create in the application, for a programmatic pull.
3. The offboarding export bundle, requested from Settings → Billing, which assembles a structured JSON bundle and gives you a download link valid for 30 days.

Be aware of what the offboarding bundle does and does not contain. It carries a coverage manifest that states its own scope explicitly, because it is a bounded bundle and not a complete copy of the database. It includes your billing records, subscriptions, invoices, charges and credits, and your customer, supplier and chart-of-accounts master data. It excludes the general ledger transaction detail, the rendered PDFs and attachments (referenced by identifier, not inlined), and the full audit log. For your ledger detail, use the CSV report exports or the API. We say this here so that no one mistakes the bundle for a full backup.

10.5 Objection and restriction

Object to processing we base on legitimate interests, or ask us to restrict processing while a dispute is resolved. Tell us why, and we will consider it and reply.

10.6 Withdraw consent

Where we rely on consent, withdraw it at any time. This does not affect processing already carried out.

10.7 Rights specific to certain regimes

• UK and EEA: you may complain to your supervisory authority, in the UK, the Information Commissioner's Office. Please try us first.
• California: rights to know, delete, correct, and to opt out of sale or sharing. We do not sell or share personal data, so there is nothing to opt out of, and we do not offer financial incentives for personal data. You may use an authorised agent.
• Other regimes: [TO COUNSEL: confirm whether Virginia, Colorado, Connecticut, Texas, Quebec Law 25, Australian Privacy Principles or other regimes apply and whether specific disclosures are needed.]

10.8 How to make a request, and what to expect

Email [DPO/CONTACT]. We will acknowledge, may ask you to verify your identity, we will not use that as a delaying tactic, and will respond within 30 days. If a request is genuinely complex we may extend, and we will tell you why before the 30 days is up. Requests are free unless they are manifestly unfounded or excessive.

10.9 We will not retaliate

Exercising a privacy right will never affect your pricing, your service level, or how we treat you.

11. International transfers

11.1 Our subprocessors are principally in the United States, and Cloudflare operates a global edge network. If you are in the UK or the EEA, using Fiskwise involves transferring personal data outside your region.

11.2 We rely on the appropriate safeguards for those transfers, Standard Contractual Clauses, the UK International Data Transfer Addendum, or an applicable adequacy decision or certification, depending on the recipient.

11.3 [TO COUNSEL: the specific transfer mechanism relied on for each subprocessor must be confirmed and recorded, and a transfer impact assessment prepared where one is required. Do not publish a general assurance until each has been verified.]

11.4 The primary hosting region is [HOSTING REGION]. We do not currently offer a choice of data residency region.

12. Security

12.1 What we actually do:

• Tenant isolation enforced by the database. Every tenant-scoped table, roughly 300 of them, has PostgreSQL row-level security enabled and forced, with an isolation policy keyed on the tenant identifier. "Forced" matters: the policy applies even to the table's owner. The application connects as a dedicated non-superuser role that cannot bypass row-level security, and the service refuses to start if it detects that it has been pointed at a privileged connection instead. Isolation is therefore a property of the database, not of application code being careful.
• Encryption in transit. The service is served over HTTPS/TLS. The application refuses to start unless its public origins are HTTPS.
• Encryption at rest for secrets. Bank aggregator access tokens, supplier payment credentials, third-party integration tokens and currency-feed API keys are each encrypted with AES-256-GCM under separate, rotatable keys held outside the database. The service refuses to start if a key is missing or malformed, so it cannot silently fall back to a default key.
• Passwords are stored only as hashes. API keys are stored only as hashes. Export download tokens are stored only as hashes.
• Two-factor authentication has server-side support today; the in-app enrollment screens are under development.
• Session cookies are HttpOnly, Secure over HTTPS, and SameSite=Lax. Cross-origin requests are restricted to an explicit allowlist and origin-checked.
• Webhooks we receive are cryptographically verified: HMAC signatures with a replay window for the payment processor, and pinned JWT signature verification for bank feed events.
• Outbound webhooks you configure are protected against server-side request forgery by resolving and validating the destination address before connecting.
• Role-based access control with granular permissions, so you can limit what each user can see and do.
• A comprehensive audit trail (section 3.8) recording who changed what.

12.2 What we do not have, stated plainly. We hold no SOC 2 report, no ISO 27001 certification, and no third-party security audit or penetration test report. Nothing in this policy or anywhere else in our material should be read as implying otherwise. If a compliance attestation is a requirement for you, we do not have one today, and we would rather you knew that before you signed up than after.

12.3 No system is perfectly secure. We cannot guarantee that data will never be accessed improperly. Section 5.3 of the Terms of Service records that account credentials are your responsibility.

12.4 If you believe you have found a security vulnerability, please report it to [DPO/CONTACT]. We will not pursue action against good-faith researchers who report privately, do not access data beyond what is needed to demonstrate the issue, and give us reasonable time to fix it.

13. Personal data breaches

13.1 If a breach affects personal data for which we are the controller and is likely to result in a risk to people's rights, we will notify the relevant supervisory authority without undue delay and within 72 hours of becoming aware of it, where the law requires. Where the risk is high, we will notify the affected individuals directly.

13.2 If a breach affects personal data for which we are a processor, data inside your books, we will notify you without undue delay after becoming aware, so that you can meet your own notification obligations. We will tell you what we know, what we are doing, and what we recommend you do, and we will keep you updated as we learn more.

13.3 We will not delay a notification in order to have a complete picture first. You will get a partial account quickly rather than a full one late.

14. Changes to this policy

14.1 We may update this policy. Every version carries a Last updated date and a version string of the form YYYY-MM-DD.n.

14.2 For a material change we will give at least 30 days' notice by email to account contacts and by an in-app notice before it takes effect. For minor corrections we will update the page and the version string.

14.3 We record which version of this policy each user accepted.

15. Contact

Privacy questions, data-subject requests and security reports:

[DPO/CONTACT]

[ENTITY] [ADDRESS]

[TO COUNSEL: confirm whether a Data Protection Officer must be appointed, and whether an EU or UK representative under Article 27 is required. If so, name and address them here.]

If you are in the UK or the EEA and are not satisfied with our response, you may complain to your supervisory authority. We would appreciate the chance to put it right first.

This document is a first draft prepared for review by qualified legal counsel. It is not legal advice, it has not been reviewed by a lawyer, and it should not be published or relied upon until it has been.