LEGAL 03Data Processing Addendum

Data Processing Addendum

Standard terms, draft of July 10, 2026 · version draft-2026-07-10

Draft — under legal review
These standard terms accurately describe how Fillall processes data today, but the legal wording has not yet been finalized by counsel. Executed DPAs will use the counsel-reviewed version.

To execute this DPA, email support@fillall.io from your account's email address with your legal entity name. We will return a countersigned copy. This page describes our standard terms — the ones you accept when creating an API key, and the baseline for any executed agreement.

01Executing this DPA

This addendum supplements the Terms of Service for customers whose use of Fillall involves processing personal data on behalf of others (for GDPR: you as controller, us as processor; for CCPA: us as a service provider). Accepting the Terms and DPA is required — and recorded — when you create an API key; organizations that need a signed instrument should contact support@fillall.io as described above.

02Roles and instructions

For the data you fill into forms, you are the controller and Fillall is the processor. We process that data only on your documented instructions — which, for a self-serve product, are the actions you take: inserting records, dispatching fills, downloading outputs, deleting data. We do not use your form data for our own purposes, do not sell it, and do not use it to train AI models.

For your account data (email, billing, usage), Fillall is itself the controller, as described in the Privacy Policy.

03Scope and purpose of processing

Processing is limited to one purpose: rendering the data you provide into filled PDF forms and giving it back to you. Concretely: storing records you choose to save, validating and expanding rows against a form's field contract, deterministic PDF rendering, temporary storage of generated outputs, and deletion on the schedules in the Privacy Policy's retention table. No profiling, no analytics on form-fill content, no secondary use.

04Categories of data and data subjects

You decide what goes into your forms, so the categories are under your control. Government and business forms typically contain identity data (names, addresses, dates of birth), government identifiers (SSNs, tax and case numbers), and financial or employment details. Data subjects are typically your clients, employees, or other individuals you file for. Fillall is built on the assumption that every cell may be sensitive — the handling rules do not vary by category.

05Duration, deletion, and return

Processing lasts as long as you use the service. Deletion is primarily self-serve and immediate on request: records and batches can be deleted (30-day recycle bin) or purged — a synchronous hard delete that removes the rows and every generated file — from the site or API at any time. Generated files also delete themselves on the plan retention clock without any action from you. On account closure we delete remaining customer form data; you can export your records and outputs beforehand via the site or API (that is the service's normal function — no special export process is needed).

06Subprocessors

You authorize the subprocessors listed on the Subprocessors page, each engaged under terms no less protective than this DPA. That page states which vendors can touch form-fill data and which cannot — in particular, AI providers analyze form structure only and never receive form-fill data. We update the page before adding or replacing a subprocessor that handles customer data; customers with an executed DPA will be notified by email and may object on reasonable data-protection grounds.

07Security measures

  • Encryption in transit (TLS) and at rest; application-layer AES-256-GCM encryption for stored service credentials.
  • Architectural separation of customer form data (regional data plane) from account/catalog data (control plane); nothing reads regional data without an explicit region.
  • Spreadsheet values are never written to the database — files are streamed row-by-row in memory during rendering.
  • Error reports and logs carry row/field/code metadata only, never cell values.
  • Separate staff authentication (password + second factor, isolated domain and session system); customer-facing code cannot write to the shared catalog.
  • API keys stored as hashes, revocable instantly, optionally IP-restricted; append-only audit log of consequential actions.
  • Automatic retention sweeps so generated files and staged uploads cannot outlive their windows.

08Data subject requests

Requests from your data subjects go to you as controller. The tooling to honor them is self-serve: their records are visible, editable, exportable, and deletable (with immediate purge) through your account and API. Where a request needs something the tooling doesn't cover, we will assist — contact support@fillall.io. If a data subject contacts us directly about data you control, we will refer them to you.

09Incident notification

If we become aware of a personal-data breach affecting your data, we will notify you without undue delay at your account email, with what we know: nature of the incident, data and accounts affected, measures taken. We will not wait for a complete investigation to send the first notice.

10International transfers

All customer data is processed and stored in the United States (database in AWS us-east-2, Ohio; file storage in Cloudflare R2's US region) — see the Privacy Policy. If you are subject to GDPR or similar transfer regimes, using Fillall today means transferring data to the US; the executed DPA is expected to incorporate the EU Standard Contractual Clauses for that transfer (the exact mechanism is part of the pending legal review). EU/APAC regions are planned; when they launch, accounts pinned to them will have their data processed there instead.

11Audit and information

We will make available the information reasonably necessary to demonstrate compliance with this DPA — this page, the subprocessor list, and written answers to security questionnaires for customers with an executed DPA. Acceptance of these terms at API-key creation is recorded in our audit log with the terms version, so both sides can establish what was agreed and when.

Related · Terms · Privacy · Subprocessors