Data Processing Agreement

1. Roles

For the operational data a client organization submits to CargoFlow (manifests, dangerous-goods declarations, aircraft configuration data, chat content, uploaded documents), the client organization acts as the data controller and CargoFlow acts as the data processor, processing that data solely to provide the Service and only on the client's instructions (as expressed through normal use of the product). Where CargoFlow determines the means of processing account-level platform operation (e.g. audit logging required for security), CargoFlow may act with limited independent purposes strictly necessary to operate and secure the Service.

2. Categories of data processed

• Account and identity data: usernames, roles, tenant assignment, password hashes.
• Operational cargo data: manifests, ULD/position data, weights, dangerous-goods declarations, aircraft configuration values.
• Communications: chat turns with the CargoFlow agent and any operational content referenced within them.
• Uploaded documents: knowledge-base and client-specific documents (manuals, procedures) used for agent grounding and search.
• Derived/operational records: generated documents (Load & Trim Sheet, LDM, CPM, UCM, NOTOC), shipper weight-reconciliation and reliability scores, and audit-log entries.
• This template does not currently contemplate special-category personal data (e.g. health data) and such data should not be submitted through the Service.

3. Duration and instructions

Processing lasts for the term of the client's subscription/order, plus any agreed post-termination export/deletion window described in the Privacy Policy. CargoFlow processes data only to provide the Service, per the client's use of it, and not for CargoFlow's own independent purposes (e.g. no use of client manifest content to train models).

4. Sub-processor disclosure

Sub-processors currently in use, as reflected in the running codebase (not a hypothetical list):

• OpenAI — text-embedding-3-small API, used to generate vector embeddings from knowledge-base and client document content when an embeddings provider is configured, to power document search for the agent.
• n8n (self-hosted workflow engine) — receives chat-turn content and uploaded aircraft-configuration documents, orchestrates the round trip to an underlying language-model provider, and returns structured results to the application. It does not independently store client data outside that orchestration.
• Underlying hosting/database infrastructure — required to run the application and its Postgres database.

CargoFlow will notify the client of any new sub-processor added to this list with material access to client data, and the client may object through the process to be defined in the signed agreement. A named, contractually binding sub-processor list (with entity names and regions) should be attached as an exhibit to any signed DPA rather than relying solely on this page.

5. Security measures

Measures actually implemented in the current system, verified against the codebase (not aspirational):

• Password hashing — user passwords are hashed with bcrypt before storage; plaintext passwords are never stored.
• Session-based authentication — authenticated access uses server-side sessions with an httpOnly, SameSite cookie; in production the session secret must be explicitly configured and the server refuses to start with an insecure default secret.
• Tenant isolation — operational data is scoped by client_id at the application/query level so one tenant's records are not returned to another tenant.
• Rate limiting — API requests are subject to rate limiting to reduce abuse and protect availability.
• Audit logging — key actions, including administrative support impersonation, are recorded with the acting user and tenant for accountability.

What we do not claim: CargoFlow does not currently hold SOC 2, ISO 27001, or any equivalent third-party security certification. Formal certification is on the roadmap but not complete, and this document must not be read as implying one exists. Encryption-in-transit relies on standard TLS for connections to the Service; specific encryption-at-rest and infrastructure hardening details should be confirmed directly with the CargoFlow team before being relied on contractually.

The public marketing site (before sign-in) also sets a first-party, self-hosted cf_visitor analytics cookie — see Privacy Policy Section 2 for exactly what it records.

6. Data subject requests and breach notification

CargoFlow will assist the client in responding to verified data-subject requests (access, correction, deletion) concerning data processed on the client's behalf, and will notify the client without undue delay upon becoming aware of a security incident affecting the client's data. Specific notification timeframes are to be agreed in the signed version of this document.

7. International transfers

Where sub-processors (e.g. OpenAI) process data outside the client's home region, appropriate transfer safeguards (such as the sub-processor's own standard contractual clauses) apply as provided by that sub-processor. Region-specific commitments should be confirmed and documented in the signed agreement if required by the client's regulator.

8. Precedence

This page is a drafting starting point. A binding DPA must be a signed document, reviewed by both parties' counsel, that may supersede or add to the terms described here.