Data-processing addendum

Roles, the subject-matter and duration of processing, the categories of data and data subject, the sub-processors, the security measures as actually implemented — and and how your data is corrected, exported and deleted at the end.

01What this addendum is

This addendum is intended to sit under the agreement and to govern the processing of personal data in a CargoSharks deployment. It is written in the vocabulary of controller and processor because that is the vocabulary most reviewers will bring to it.

This addendum follows the article-28 pattern because it is the most demanding of the regimes that may apply. Which law governs a particular engagement depends on the hosting region and on where the controller is established, and is recorded in the agreement.

02Roles

The customer is the controller: The forwarder decides whose data goes into the deployment, which mailboxes are connected, whether the model surface is enabled, who may see what, and for how long records are kept.
CargoSharks is the processor: CargoSharks Freight Technologies processes personal data in the deployment only to provide and support the service.
For its own website and sales: CargoSharks is a controller in its own right. That is covered by the privacy policy, sections 03 and 04, and is outside this addendum.

Because the product is supplied one deployment per customer — one database, one schema, no tenant identifier above the branch — there is no processing of one controller’s data in a system shared with another controller’s. That removes an entire category of question a reviewer would otherwise have to ask.

03Subject-matter, duration, nature and purpose

Subject-matter: Personal data contained in the records of a freight-forwarding business: the people who work for the forwarder, the people who work for its customers and agents, the people who receive goods at the door, and the people who correspond with a connected mailbox.
Nature of the processing: Storage, structuring, retrieval, use, generation of documents, transmission by email and webhook, and — where the controller enables it — disclosure to a model provider for extraction and question answering.
Purpose: Operating the forwarder’s commercial and operational record: pricing, quoting, executing, documenting and invoicing a freight job, and giving its customers and agents visibility of the parts that concern them.
Duration: The term of the agreement, and afterwards for as long as the deployment and its backups exist. See section 14, which explains why that sentence is not the usual one.

04Categories of data and of data subject

Read this beside privacy, section 05, which carries the same list with more detail. In summary:

Data subject	Categories of personal data
The controller’s staff	Name (English and Arabic), work email, phone, interface language, active flag, last seen. Authentication records: hashed password, session token, IP address, user-agent, two-factor secret and backup codes where enabled.
Contacts at customers and agents	Name (English and Arabic), email, phone, job role, primary-contact flag, notification opt-outs.
Recipients of goods	Name, identity-document number, an image of a handwritten signature, GPS coordinates and accuracy of the delivery point, photographs taken at delivery, and any exception note.
Correspondents	Everything in a message read from a connected mailbox: sender, all recipients and copies, subject, full body text, timestamps, and attachments.
Named parties on documents	Shipper, consignee and notify-party names and addresses.
Anyone appearing in data a model reads	Whatever is in the email or the document that was sent. Stored verbatim in the deployment’s own model ledger. See section 10.

Two categories deserve a reviewer’s attention. The proof-of-delivery record holds an identity-document number, a signature image and a precise location, about a person who never entered into any relationship with the controller’s software supplier. The mailbox records hold the contents of correspondence, including from people who wrote in about something else entirely. Neither is unusual for the industry; both are the parts most likely to attract a question. The field is optional in the schema, and a controller who does not need it should leave it unused.

05Processing only on instructions

CargoSharks processes personal data in the deployment only on the controller’s documented instructions, which the agreement, this addendum and the controller’s own configuration of the product constitute.
The product’s external connections are all off by default and are turned on by the controller, with the controller’s own credentials. Enabling one is an instruction; there is no vendor account behind any of them.
Controller data is not used to train, fine-tune or evaluate any model, by us or on our behalf.
If an instruction appears to us to breach applicable data-protection law, we tell the controller without delay and may suspend the affected processing until it is resolved.

06Confidentiality of personnel

Everyone with the possibility of access is bound to confidentiality. In practice the number of people who can access a deployment’s data at all is bounded by the mechanism in section 07 rather than by a policy: without a grant from the controller’s own administrator, there is no path in.

Everyone with support access is bound by a written confidentiality obligation that survives the end of their engagement. Access is not standing: it exists only while a grant the customer wrote is unexpired, and the customer can see it and revoke it at any time.

07Security measures, as implemented

Each row below is a property of the build, not an intention. Where a measure has a limit, the limit is in the row.

Measure	How it is implemented, and its limit
Separation between controllers	One deployment per customer: a separate database and a separate instance. No shared table, no tenant column.
Separation inside a deployment	Row-level security policies in the database, keyed on what kind of principal is asking — staff by branch, a customer contact by customer, an agent contact by the jobs they are party to, everyone else denied. The application connects as a role that cannot bypass them and owns no table. An unauthorised request returns not-found rather than a filtered list.
Access control	Permissions per role and branch, checked in the application as well as in the database on the stated principle that neither is trusted alone. Sessions are opaque database-backed references, twelve hours, revocable immediately. Two-factor authentication is enforced for the Administrator and Finance roles. Lockout after repeated failures is built, as is per-address rate limiting.
Audit trail	Database triggers on every business table, recording time, principal and principal type, table, row, operation, the whole row before and after, branch, and source IP. Update, delete and truncate on the log are revoked from the application role and from public. The schema-owning role can still alter it; it is not used at runtime and migrations are applied by continuous integration from tagged commits.
Immutability	Delete and truncate revoked from the application role on every table; future tables inherit select, insert and update only. Files are retired by moving them, not by removing them.
Encryption of stored credentials	AES-256-GCM with a fresh 96-bit initialisation vector per value, scheme-versioned. The 32-byte key comes from the environment and is never in the database, so a backup or a replica carries ciphertext without a key. A database constraint refuses an unsealed mailbox password. API keys are hashed with Argon2id.
Encryption in transit	Outbound connections to the model provider, the carriers and the rates feed are HTTPS. SMTP requires TLS with certificate verification on by default; IMAP uses implicit TLS or STARTTLS. Session cookies are marked secure in production. See section 08 for what is not covered.
Support access	Granted by the controller’s administrator, scoped to named branches, requiring a non-empty reason, read-only by default and structurally so, expiring within eight hours at most, revocable in one click, announced by a banner on every internal screen, and logged once per database transaction to an insert-only log the controller can read.
Backup and restore	Per-deployment dumps taken through an administrative connection — the tool refuses the application account, because row-level security would make such a dump silently partial. Restores are drilled into a scratch database and verified by row count and schema. Retention, off-site copying and encryption of the dumps are not implemented by the tooling and belong to the storage they are written to.
Verification	Row-level security is applied to every business table and an audit trigger to every business table, asserted by the project’s own test suite — a new table with no policy fails the build. That is verification by the supplier. It is not an independent attestation, and none exists.

08Security measures not yet in place

Listed rather than omitted. A reviewer who finds these on their own will discount everything in section 07.

The database connection does not require TLS. Nothing in the code specifies it. Traffic between the web and service containers is plain HTTP on a private network, by design.
Encryption at rest for the database is not established. It depends on a host that has not been chosen.
No independent security testing. No penetration test, no SOC 2, no ISO 27001.
There is no data-erasure mechanism, and retention periods are not set. See section 11.
Monitoring and alerting are not in place.
Audit search and export is specified and not built — the log is complete and readable, but there is no screen that searches or exports it.

Closed on 25 August 2026, and recorded here rather than quietly dropped: the application now sets a full set of security headers, including a content-security policy with a per-request nonce and HSTS; sign-in lockout and a per-address rate limit are built; and two-factor authentication is enforced for the Administrator and Finance roles.

09Sub-processors

The unusual thing about this list is that the controller appoints all of them. Every external service is off by default and is configured by the controller with the controller’s own credentials; the software holds no vendor account for any of them. In the strict sense most are the controller’s own processors rather than our sub-processors, and a reviewer should read the list that way.

Category	Who	What it receives
Object storage	Any S3-compatible provider the controller points at (Cloudflare R2, MinIO, Backblaze, AWS S3 — the product signs the requests itself and names no vendor).	Every document byte: generated PDFs, email attachments, uploaded scans, proof-of-delivery signatures and photographs, compliance documents, letterheads.
Model provider	OpenRouter, and whichever model the controller configures it to route to. Off unless the controller supplies a key.	See section 10 — it is the row that needs more than a cell.
Outbound mail	The controller’s own SMTP relay.	Recipients, subjects, bodies in either language, attachments.
Inbound mail	The controller’s own IMAP host, one mailbox per branch.	Nothing is sent to it. The product reads from it: bodies, headers, attachments.
Carrier tracking	Maersk, Hapag-Lloyd, CMA CGM, over DCSA, on the controller’s own credentials. Built; not running anywhere today.	Container, bill-of-lading and booking numbers. No personal data by design.
Exchange rates	A public rates endpoint.	Currency codes only.
Outbound webhooks	Whatever URL the controller configures.	Whatever events the controller subscribes to. A controller-directed transfer.

Not present, and worth saying because a reviewer will look: no payment processor, no analytics, no advertising or marketing platform, no error-reporting service, no product-telemetry exporter, no appointed e-invoicing provider, no WhatsApp sender. The application is instrumented against the OpenTelemetry interface with no exporter configured, so nothing is emitted unless the controller configures a collector.

We give the controller thirty days’ written notice before we engage or replace a sub-processor. The controller may object in writing within that period on reasonable data-protection grounds. If we cannot resolve the objection, the controller may terminate the affected service without penalty.

10The model surface, in detail

This is the part of the system that moves personal data furthest, and it is off until the controller turns it on. Three surfaces use it:

Reading an enquiry. The subject and body text of an inbound email are sent, truncated. What comes back is a proposal a coordinator accepts or rejects; nothing becomes a record without a person saying so.
Reading a supplier invoice. The whole document is inlined into the request — not a link to it, the bytes. A commercial invoice or a customs document therefore leaves the deployment in full. This is the single most consequential sentence in this addendum for a controller with residency obligations.
The assistant. It answers questions over the controller’s own data. Its tool calls run under the asking person’s own database policies, so it can see exactly what that person could see on a screen and nothing else. What is sent to the model is the rows those calls returned.

Two properties of the arrangement matter:

OpenRouter is a router, not a model vendor. The request is forwarded to whichever provider serves the configured model, and the model actually served may differ from the one requested — the deployment records both, for exactly this reason. Which company processed the request, and where, is not something the product is told.
Every request and response is kept, verbatim, in the deployment. That includes any document that was inlined. It is a deliberate design decision: after a prompt-injection incident the first question is what the model actually saw, and a system that cannot answer it cannot be investigated. It also means the ledger is a second copy of the most sensitive payloads in the system, inside a database that cannot delete.

A controller with data-residency obligations should leave this surface switched off, and we advise that in writing. It is inactive unless a key is configured; removing the key removes it entirely, with no partial state and no residue.

11Assisting with data-subject requests

What can be done, mechanically, and what cannot:

Access: Yes. A deployment can be queried for every record naming a person, and the audit log read for every change that touched them.
Rectification: Yes, and it leaves a trace. Correcting a record supersedes it rather than overwriting it. The wrong value is corrected going forward; it is not unwritten, and it remains in the audit log’s before-and-after copy.
Portability: Yes, on request. An export in an open format is available. A single self-service action producing a complete export is specified and not built; today it is assembled on request.
Restriction and objection: Partly. An account can be deactivated and a contact marked inactive or opted out of notifications, immediately. Neither removes anything.
Erasure: No. There is no mechanism.

That last line deserves the detail, because it is the one a reviewer will test.

The application’s database account cannot delete or truncate on any table — the privileges it holds are select, insert and update — and a retired file is moved under a retired/ prefix rather than shredded. Records are corrected by superseding them, not by erasing them, so there is no in-place erasure of a single person mid-engagement. The honest answer to that request is correction, above; and, at the end of the engagement, deletion of the whole deployment, which is the controller’s to make (section 14).

Why the design is like this, and what it buys. Immutability is what makes the audit trail worth having. It is why a quotation revision cannot quietly replace what a customer accepted, why a document cannot change after it was issued, and why a dispute six months later can be settled from the record. Freight also carries statutory retention obligations of its own, which frequently outlast any request to be forgotten. None of that makes the absence of an erasure path acceptable by itself — it makes it a decision that has to be taken deliberately.

12Personal data breach

We notify the controller without undue delay after becoming aware of a personal data breach affecting their deployment, and give them what they need to make their own notification.

We notify the controller within 24 hours of becoming aware of a personal-data breach affecting their deployment, by email to their named administrators. A first notification states what is known, what is not yet known, what we are doing, and when the next update will come. It is not delayed for the sake of being complete.

What the deployment can supply towards an investigation is genuinely strong and worth stating: the audit log carries every change to every business record with the acting principal, the source IP and the whole row before and after; the support access log carries every session opened under a grant; and the model ledger carries every request and response verbatim. What it does not carry is a user-agent string on anything but the session record, and there is no request identifier tying an audit row to a specific HTTP request.

13Impact assessments and prior consultation

We assist the controller with impact assessments and with any prior consultation, given the information available to us. This document, and the privacy policy, are most of that information: they are written from the code precisely so that an assessment does not have to be based on a brochure.

Two things in the product are the likely subject of an assessment: the proof-of-delivery record (identity number, signature image, precise location) and the model surface (section 10). Neither is hidden in this document for that reason.

14Return and deletion at the end

Return is straightforward. An export in an open format is available on request, during the term and for a period afterwards. The schema is documented. There is nothing to disentangle because your database was never entangled with anyone else’s.
The data is yours. The deployment is your own database, in your own instance, and it can run on your own infrastructure. We do not own the controller’s data, and where you host it yourself we hold no copy of it.
So deletion at the end is the controller’s to make, not ours to withhold. The deployment stays available for thirty days after termination so that a full export can be taken; after that, on the controller’s written instruction, what remains — the database, the object store including its retired/ prefix, and the backups taken from them — is destroyed, by you where you host it and by us where we host it for you.

15Audits and inspections

The controller can already audit one thing without asking us: every support grant ever issued, with the access count against it, is on their own settings screen and comes from an insert-only log. That is the part of a processor relationship customers most often cannot verify, and here they can.

Beyond that, a controller may audit our compliance with this addendum once in any twelve-month period, on thirty days’ written notice, at their own cost, and through an auditor who is bound by confidentiality and is not a competitor of ours. There is no independent attestation to offer in its place; what we give instead is the measures in section 07, the sub-processor list, and answers in writing.

16International transfers

The deployment stays in the region chosen with the controller and recorded in the agreement. What leaves it is only what the controller switched on: model requests (section 10), mail to the relay they configured, and webhooks to the URLs they chose — and the model surface is inactive unless the controller enables it.

17Liability and precedence

Liability under this addendum is subject to the limitations in the agreement. Where this addendum and the agreement conflict on the processing of personal data, this addendum prevails.

18Contact

[email protected] reaches a person.

Data-protection notices under this addendum go to [email protected]. Breach notifications and security reports go to [email protected].

Status Effective on signingWritten 25 August 2026, from the CargoSharks codebaseYour data is yours corrected in place on request, exported at the end, and deleted at your instruction

The set

Three documents

Privacy policyWhat is held, where, by whom, and for how long.Terms of serviceWhat is supplied, what is owed on each side, and where the limits are.Data-processing addendumRoles, sub-processors, security measures, and how your data is corrected, exported and deleted. You are reading it.