Legal

Tablinum Data Processing Agreement

Version 2026-10-17. Permanent address of this version: tablinum.app/legal/data-processing-agreement/2026-10-17

Version: 2026-10-17 · Effective: not yet in effect (a draft, published 2026-10-24 for review). The final text will carry a new version date.

This Data Processing Agreement ("DPA") forms part of the Tablinum Terms of Service (the "Terms") between [TABLINUM ENTITY NAME] ("Tablinum") and the Customer named in the Terms ("Customer"). It applies whenever Tablinum processes Customer Personal Data. Capitalized terms not defined here have the meanings in the Terms.

1. Definitions

• "Customer Personal Data" means personal data within Customer Data that Tablinum processes on Customer's behalf in providing the Service.
• "Data Protection Laws" means the privacy and data-protection laws that apply to a party's processing of Customer Personal Data. They include, where applicable, the California Consumer Privacy Act as amended ("CCPA"), the other US state comprehensive privacy laws, and the GDPR and UK GDPR.
• "personal data," "controller," "processor," "data subject," "processing," "business," "service provider," "sell," "share" and "consumer" have the meanings Data Protection Laws give them. "Personal data" includes "personal information".
• "Security Incident" means a confirmed breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to, Customer Personal Data. It does not include unsuccessful attempts that do not compromise security, such as pings, port scans, blocked sign-in attempts or denial-of-service attacks.
• "Subprocessor" means a third party Tablinum engages that processes Customer Personal Data.

2. Roles

2.1 Customer is the controller; Tablinum is the processor. Customer is the controller (or "business") of Customer Personal Data, or a processor acting for another controller. Tablinum is Customer's processor (or "service provider"/"processor" under US state laws).

2.2 Tablinum's own processing is outside this DPA. Tablinum is an independent controller for the limited personal data it needs to run its relationship with Customer and to operate the platform. That data is:

• Customer's Owners' and billing contacts' details, and Tablinum's invoices and payments;
• records of acceptance of the Terms, this DPA and Tablinum's user terms;
• security logs and records of actions by Tablinum personnel;
• Service Data and aggregated or de-identified data, as section 12.4 of the Terms describes.

Tablinum's Privacy Policy describes this processing. Even so, Tablinum applies the security measures in Annex 2 to all of it.

2.3 Customer's obligations. Customer is responsible for having a lawful basis for the processing, for giving its data subjects the notices it must give (including to its Clients and its employees), and for obtaining any consents it needs. Customer's instructions must comply with Data Protection Laws.

3. Processing on instructions

3.1 Tablinum processes Customer Personal Data only on Customer's documented instructions, unless the law requires otherwise (in which case Tablinum will tell Customer first, unless the law forbids that). Customer's instructions are:

• the Terms and this DPA;
• Customer's configuration and use of the Service, including actions by its Authorized Users and the integrations it connects;
• any further written instructions Tablinum agrees to.

3.2 Tablinum will tell Customer if, in its opinion, an instruction infringes Data Protection Laws. Tablinum may then decline to follow that instruction.

3.3 Annex 1 describes the processing.

4. Confidentiality and personnel

Tablinum ensures that everyone it authorizes to process Customer Personal Data is bound by confidentiality. Tablinum also limits access to personnel who need it to provide, secure or support the Service.

Tablinum personnel sign in to a separate console that requires an authenticator app. Where they act inside Customer's shop, they do so through a time-limited support session. Every action in that session is recorded in Customer's activity log, and every Owner is emailed if support changes anything [support sessions: not yet built].

5. Security

5.1 Tablinum implements and maintains the technical and organizational measures in Annex 2. They are designed to protect Customer Personal Data against Security Incidents and to ensure a level of security appropriate to the risk.

5.2 Tablinum may update these measures, provided the update does not materially reduce the overall protection of Customer Personal Data.

5.3 Customer is responsible for its own security choices in the Service. These include who it invites, the roles it assigns, whether it requires authenticator apps for staff who handle money and for Clients who can buy, and keeping its users' email accounts secure.

6. Subprocessors

6.1 General authorization. Customer authorizes Tablinum to engage the Subprocessors listed at tablinum.app/legal/subprocessors, and new Subprocessors under this section.

6.2 Flow-down. Tablinum has a written agreement with each Subprocessor that imposes data-protection obligations at least as protective as this DPA, appropriate to the service it provides. Tablinum remains responsible for each Subprocessor's performance of those obligations.

6.3 Notice of new Subprocessors. Tablinum will update the list, and notify Customer's Owners by email, at least 30 days before a new Subprocessor begins processing Customer Personal Data. In an emergency, such as replacing a failed provider to keep the Service running, Tablinum may give notice as soon as practicable instead.

6.4 Objection. Customer may object on reasonable data-protection grounds within the notice period. The parties will discuss the objection in good faith. If Tablinum cannot reasonably accommodate it, Customer may terminate the affected part of the Service by notice before the change takes effect. That termination is Customer's sole remedy for the objection, and Customer pays no fee for any period after it.

6.5 Integrations Customer chooses. Third-party services that Customer connects or uses under its own agreement are not Tablinum's Subprocessors. These include Customer's own Stripe account, QuickBooks Online and, when available, HubSpot. Sending data to them is processing on Customer's instruction (section 8 of the Terms). The subprocessor list describes these separately.

7. Data subject requests

7.1 Forwarding. If Tablinum receives a request from a data subject about Customer Personal Data, it will not respond on the merits. Instead it will direct the requester to Customer and notify Customer promptly, unless the law forbids that. Erasure requests in particular go through Customer's Owner, never to Tablinum directly.

7.2 Self-service tools. Customer can use the Service to:

• find, view and export records about a person;
• correct a person's details;
• archive records and staff accounts, and close portal accounts;
• [not yet built] permanently delete a file's contents, including all its versions, with the "delete forever" action. What remains is a record that the file was deleted, the file's name and fingerprint in audit and transmittal records, and legal financial documents already issued, such as accepted quotes, invoices and credit notes.

7.3 What the Service does not do automatically. Most records in the Service are archived rather than erased when a user deletes them, and orders, invoices and their history are kept for the life of the shop. The Service does not yet have a tool to erase one person's identifying details from the records that remain.

If Customer needs that for a data subject request, Tablinum will, on request, remove or replace the person's identifying details while keeping the business records intact. It will do so within [30] days, or a longer period Data Protection Laws allow.

7.4 Assistance. Taking into account the nature of the processing, Tablinum will provide reasonable assistance so Customer can meet its obligations to respond to data subject requests.

8. Assistance with assessments

Tablinum will provide reasonably available information to help Customer carry out data-protection impact assessments, risk assessments and prior consultations that Data Protection Laws require about the Service.

9. Security Incidents

9.1 Notice. Tablinum will notify Customer's Owners without undue delay, and in any case within 72 hours, after confirming a Security Incident affecting Customer Personal Data.

9.2 Content. The notice will describe, to the extent known:

• the nature of the incident;
• the categories and approximate number of data subjects and records affected;
• the likely consequences;
• the measures taken or proposed.

Tablinum will add further information as it becomes available.

9.3 Response. Tablinum will promptly take reasonable steps to contain and remediate the incident, and will reasonably cooperate with Customer, including on notices Customer must give to data subjects or regulators.

9.4 No admission. Notice of a Security Incident is not an admission of fault.

9.5 Public explanation. For incidents affecting Customer Data, Tablinum also publishes a plain-language explanation on its status page, without identifying Customer.

10. Return and deletion

10.1 During the subscription. Customer may obtain a complete export of Customer Data at any time, at no charge, as section 12.2 of the Terms describes.

10.2 On cancellation. Tablinum automatically prepares a complete export when the subscription is cancelled. It keeps Customer Data available read-only for 60 days, then deletes it as section 11 of the Terms describes: from use at day 90, and permanently from production systems at day 120.

Backup copies expire on their normal schedule:

• database backups within [30] days, plus a 7-day point-in-time recovery window;
• file backup copies within 90 days.

Until expiry, backups are protected under Annex 2 and used only to restore after a failure.

10.3 Retained records. Tablinum may keep Customer Personal Data where the law requires it. It may also keep the limited records described in section 11.2 of the Terms, which Tablinum holds as controller. Any such data stays protected and is used only for the purpose it is kept for.

10.4 Certification. On request after day 120, Tablinum will confirm the deletion in writing.

11. Audits and information

11.1 What Tablinum provides. On reasonable request, Tablinum will make available information necessary to demonstrate compliance with this DPA, which may include:

• a current description of its security measures;
• its most recent independent audit report (Tablinum is working toward a SOC 2 report and will provide it once available);
• answers to a reasonable security questionnaire, no more than once a year.

11.2 Further audits. If that information is not enough to demonstrate compliance, as a regulator or Data Protection Laws require, Customer may audit Tablinum's relevant processing itself or through an independent auditor bound by confidentiality, on these conditions:

• at least [30] days' notice;
• no more than once a year, unless a Security Incident has occurred;
• during business hours, without access to other customers' data;
• at Customer's expense.

12. US state privacy law terms

Where Tablinum processes Customer Personal Data as a service provider or processor under the CCPA or another US state privacy law, Tablinum:

• (a) processes it only for the business purposes of providing, securing, supporting and improving the Service under the Terms, as specified in Annex 1;
• (b) does not sell or share it;
• (c) does not retain, use or disclose it for any other purpose, including any commercial purpose other than the business purposes in (a), or outside the direct business relationship with Customer, except as the law permits;
• (d) does not combine it with personal data Tablinum receives from or on behalf of others, or collects from its own interactions with the consumer, except as the law permits a service provider to do;
• (e) complies with the applicable obligations of those laws and provides the same level of privacy protection they require;
• (f) notifies Customer if it determines that it can no longer meet its obligations under them;
• (g) allows Customer, on notice, to take reasonable and appropriate steps to stop and remediate unauthorized use of Customer Personal Data;
• (h) binds its Subprocessors in writing to these same obligations.

Tablinum certifies that it understands and will comply with these restrictions.

13. International transfers

13.1 Hosting. The Service is hosted in the United States (Annex 1). Some Subprocessors may process data in other countries, for example where a content-delivery network serves a request from its nearest data center. The subprocessor list states where each one processes.

13.2 Standard Contractual Clauses. Where the GDPR or UK GDPR applies and Customer Personal Data is transferred from the EEA, UK or Switzerland to Tablinum in a country without an adequacy decision, the following are incorporated by reference:

• the EU Standard Contractual Clauses (Commission Implementing Decision (EU) 2021/914), Module Two (controller to processor) or Module Three (processor to processor) as applicable, with Annexes completed from Annex 1 and Annex 2 of this DPA;
• for the UK, the International Data Transfer Addendum;
• the Swiss adaptations.

Clause 7 does not apply. Under Clause 9(a), Option 2 applies, with the notice period in section 6.3. Under Clause 11, the optional language does not apply. Clauses 17 and 18 select the law and courts of [Ireland]. [Counsel: or, if Tablinum certifies, rely on the EU-U.S. Data Privacy Framework.]

14. Liability and term

14.1 Each party's liability under this DPA is subject to the limitations and exclusions in the Terms, except where Data Protection Laws do not allow that.

14.2 This DPA lasts as long as Tablinum processes Customer Personal Data, including after the Terms end until the deletion in section 10 is complete.

14.3 If this DPA conflicts with the Terms on the processing of personal data, this DPA wins. If the Standard Contractual Clauses apply and conflict with this DPA, the Clauses win.

---

Annex 1: Details of the processing

Categories of data subjects

• Customer's Authorized Users: employees, contractors and shop-floor staff.
• Customer's Clients: the individuals at Customer's client organizations who use the portal, and individuals who sign up as individual clients.
• Contacts Customer records at its client organizations and its vendors and subcontractors.
• Any individual whose information appears in files or documents Customer uploads.

Categories of personal data

• Identity and contact: first and last names, email addresses, phone numbers, postal addresses, job titles, organization names.
• Account and security:
  • roles and permissions;
  • password hashes;
  • authenticator-app secrets (encrypted);
  • shop-floor quick-login PIN hashes;
  • session records;
  • sign-in and confirmation-code records.
• Commercial records:
  • requests, quotes, orders and their history;
  • accepted-quote snapshots;
  • invoices, credit notes, payments and refunds;
  • account credit;
  • tax-exemption certificates;
  • purchase orders.
• Payment references: Stripe identifiers, card brand, last four digits and expiry, bank name and last four digits. Full card and bank numbers are never processed by Tablinum; Stripe receives them directly.
• Work and time: time punches and timesheets, job assignments, and labour cost rates Customer sets for its staff.
• Evidence of acts:
  • when a Client viewed a quote;
  • acceptances, signatures and electronic-records agreements, with the time, IP address and browser;
  • Customer's audit and activity records.
• Communications: comments and notifications within the Service, and records of email sent through it (recipient, type, status; not the message body).
• Files: drawings, models, documents and other files, which may contain any personal data Customer includes.

Sensitive data. None is intended. Section 6.7 of the Terms restricts it.

---

Annex 2: Technical and organizational security measures

Each measure below is in place in the Service today unless marked [not yet built] or [planned].

1. Tenant isolation

• Each shop's data is separated in the database by row-level security that is enabled and forced on every shop table. The application's database role cannot bypass it, and an automated check fails any shop table that lacks it.
• A request's shop is determined from the hostname, which Tablinum's edge sets in a header authenticated by a shared secret. It is never taken from request parameters.
• Accounts are per shop. Sign-in cookies are host-only, so a session never carries from one shop to another, or from the staff app to the client portal.

2. Encryption

• In transit: all traffic uses HTTPS through Cloudflare's edge [VERIFY: minimum TLS 1.2 set on the zone]. Database connections are refused unless encrypted.
• At rest: databases, backups and secrets are encrypted at rest by Google Cloud (AES-256). Files in Cloudflare R2 are encrypted at rest by Cloudflare.
• In the application: authenticator-app secrets and the access tokens of connected integrations (such as QuickBooks) are additionally sealed with application keys, which are rotated without downtime.

3. Authentication and sessions

• Passwords are optional. Where used, they are hashed with argon2id, must be at least 15 characters, and are checked against known-breached passwords (a k-anonymity range query) and a common-password list.
• Sign-in links and codes are single-use, expire after 10 minutes, are stored only as hashes, and are confirmed by an explicit button rather than by opening the link.
• Authenticator apps are optional for staff and Clients. A shop can require them for staff who handle money and for Clients who can buy. They are mandatory for Tablinum personnel.
• Access tokens last 10 minutes. Sessions use rotating refresh tokens with reuse detection. Sessions end after 7 days idle or 30 days in all (Tablinum console: 30 minutes and 12 hours).
• Sensitive actions require a fresh emailed code. These include refunds, voids, credit notes, role changes, invitations, archiving or restoring staff, resetting authenticator apps, changing payment details and plan changes.
• Repeated failed codes end the person's sessions. Sign-in and code emails are rate-limited per recipient.
• Public client sign-up is protected by Cloudflare Turnstile.

4. Authorization

• Role-based permissions within each shop. Nobody changes their own role, and only an owner acts on an owner.

5. Tablinum personnel access

• Tablinum personnel use a separate console at a separate hostname, with password plus mandatory authenticator app, host-bound cookies and origin checks.
• Roles are admin and support. Every console command that changes something is recorded as that person's act.
• [not yet built] Support sessions inside a shop are time-limited (at most 1 hour), mirror exactly one shop user, cannot move money or take code-protected actions, are recorded in the shop's activity log, and email every owner when they change anything.

6. Files

• Uploads go directly to storage through short-lived signed URLs, into a quarantine area.
• Each file is scanned for malware (ClamAV, run by Tablinum) before it becomes available.
• Downloads use short-lived signed URLs. File contents never pass through the application servers.

7. Payment data

• Card and bank details are entered only into Stripe-hosted fields and pages and never reach Tablinum's servers.

8. Audit and logging

• An append-only audit log records sign-ins, permission and role changes, money actions, acceptances and other significant events, in the same database transaction as the change. Application roles cannot alter or delete it.
• Security events are also written to structured logs, with a server-assigned request ID.
• [planned for launch] A shop-facing activity log view.

9. Infrastructure and change management

• Production and non-production run in separate Google Cloud projects. Non-production uses fictional data only.
• Infrastructure is defined as code.
• No long-lived cloud service-account keys exist: deployments use short-lived federated credentials, and production IAM changes are made only by the founder.
• Secrets are held in Google Secret Manager and never logged.
• Every change is made through a reviewed pull request with automated tests. Python dependencies are pinned with hashes.
• Staging, within the production project, is restored from production backups for release testing. It is protected as production is: the same access, scope and logging. Before use, sessions, sign-in codes, third-party credentials and payment-account links are removed, and outgoing mail is held. Each refresh replaces the earlier copy, so a shop deleted in production is gone from staging at the next refresh, and staging is refreshed or deleted within the deletion timeline of section 11 of the Terms. Before anyone other than Tablinum's own personnel can reach staging, personal data and files are scrubbed on each refresh.

10. Availability and backups

• The database has automated daily backups kept for 30 days, a 7-day point-in-time recovery window, and deletion protection.
• Files are copied nightly to Google Cloud Storage (Coldline, us-central1). The copy never mirrors deletions, so it can recover from mass deletion.
• The database runs as one instance until the first paying shop, after which regional high availability is enabled [planned].
• Restore drills are run quarterly, with the first before any public backup claim [planned].
• A status page and alerting are in place [planned: status page].

11. Incident response

• A documented incident-response process [planned, as part of the SOC 2 program], notification under section 9, and public plain-language explanations of incidents affecting data or lasting over 30 minutes.

12. Compliance program

• SOC 2 (Security, Availability, Confidentiality) is the target: Type I once paying shops are live, preceded by a penetration test, then Type II [planned].

---

Annex 3: Subprocessors

See the subprocessor list at tablinum.app/legal/subprocessors.