Security and subprocessors

Last updated 16 August 2026

Short answers

The questions that open most security questionnaires, answered in one place.

1. What the product is, and what data it holds

Cargease is freight operations software. A company that imports or exports uses it to track shipments and to collect the documents each shipment needs from its suppliers, customs brokers and carriers.

The data it holds is therefore:

• Shipment records: references, routes, dates, containers, incoterms, commodity and tariff classification, costs and invoice amounts.
• Business contacts: the name, email address and company of the person at a supplier, broker or carrier who is responsible for a document. Entered by the customer, not collected from the contact.
• Trade documents: bills of lading, packing lists, certificates of origin and analysis, commercial invoices, proofs of delivery, and similar files uploaded by the customer or by a participant on the shipment.
• Account users: name, email address and role for the customer's own staff who sign in.

It holds no payment card data, no government identity numbers, no health data, and no consumer data. Almost all personal data in the system belongs to the customer, not to us: they decide what goes in and what comes out. The privacy notice sets out that controller / processor split in full.

2. Hosting and subprocessors

Cargease is a web application. There is nothing to install, and it requires no access to your network, your ERP or your email. These five providers process customer data on our behalf, and no others.

Changes are announced. If we add or replace a subprocessor that handles customer data, we will tell account administrators by email before it starts processing, and update this page.

Data location and transfers

Structured data lives in the United States. Documents live on Cloudflare's network. Nothing is stored in Mexico or the European Union. If your policy requires data residency in a specific country, Cargease cannot meet that today, and we would rather you learn it here than three weeks into a procurement process.

3. Who can sign in

There are no passwords. A user enters their email address and receives a single-use link that expires in 15 minutes. Nothing reusable is stored, so there is no password database to breach, no reuse of a password leaked elsewhere, and no reset flow to attack.

There is no self-service signup, and this is enforced twice. The application refuses to send a link to an address that has no account, so it cannot be used to send unsolicited mail from our domain. Independently of that, the layer that creates user records is disabled outright, so even a valid link clicked by an unknown address cannot bring an account into existence. New users are added only by an administrator of an existing account, or by us when a customer is set up.

Sessions are held in a signed, HTTP-only, secure cookie. An administrator can remove a user from the team page at any time, which ends their access.

Roles

4. Tenant isolation

Every customer is a separate account, and every shipment, company, document and user record carries the account that owns it. Reads and writes are scoped to the account of the signed-in user, so a record belonging to another customer cannot be reached even with a valid session and a guessed identifier. The query does not match, and the response is a 404 rather than a denial that would confirm the record exists.

Document downloads are checked the same way. A file's parent record must resolve to the caller's own account before a single byte is returned, and a file whose parent cannot be resolved fails closed.

5. External parties never get an account

This is the part of the design most worth understanding, because it is where a competing product would have you provisioning logins for every supplier and broker you deal with.

Suppliers, brokers and carriers do not have accounts and never sign in. When a customer requests a document, that one contact receives a link. The link is the entire extent of their access, and it:

• carries a 192-bit random token, not a guessable identifier;
• expires 30 days after it is issued;
• opens only the documents assigned to that one party, in that one role, on that one shipment, and not the shipment's other documents, not its costs, not its other participants, and nothing at all about any other shipment;
• is upload-only. The page offers no way to download or open a file, including files uploaded through that same link;
• is revoked immediately when that participant or role is removed from the shipment, or the shipment is deleted.

A recipient supplies files and nothing else. The application does not ask them for their name, their email address or any other personal detail, because the customer already entered those when they requested the document.

6. Documents

• The bucket is private. No object is publicly readable. Every download passes through the application, where the caller's account is checked first, and files are always served as an attachment rather than rendered in the browser.
• Uploads go straight from the browser to storage over a URL signed for one specific file and valid for ten minutes. Large scanned documents therefore never pass through an intermediate server.
• File types are restricted to documents, images and spreadsheets. Archives and executables are refused.
• Size is capped at 25 MB, and the cap is enforced against the size storage actually measured, not the size the browser claimed.
• Storage keys are constructed by us from internal identifiers and sanitised filenames. A caller cannot craft a name that reaches another file.

7. Availability, backup and recovery

We do not offer a contractual SLA, and we will not quote you an uptime figure. A number stated in a sales conversation becomes an expectation, and we will not commit to one we do not yet have the history to stand behind. What we do commit to is concrete:

• The application exposes a public health endpoint that verifies it can actually reach its database, rather than merely returning a page. It is deliberately terse, reporting only healthy or degraded, because driver errors would otherwise disclose internal hostnames. External uptime monitoring against that endpoint is being added as the first customers come on; we are not going to claim it before it is running.
• We tell you before you notice. If there is an incident affecting your shipments, the expectation is that you hear it from us.
• Most failures roll back in minutes. Every previous version of the application is retained and can be promoted back into production immediately.
• The database supports point-in-time restore covering the last 6 hours, which covers the case a code rollback cannot: a bad data change that a new deployment does not undo. We are candid that six hours is short: it is the current plan's limit, and it is being extended.
• There is a written incident runbook, covering triage, rollback, the database-restore path, and what to tell a customer during a live cut-off window.
• No 24/7 coverage, and no contractual service credits. Say so out loud rather than discover it during an incident.
• Month-to-month, with no minimum term. If the service does not perform, you stop paying next month. We are clear that this addresses lock-in and not operational dependency.

8. Change management

Changes are deployed from version control to a hosted platform that keeps every previous deployment and can restore one in about two minutes. Database schema changes run as reviewed, versioned migrations. Production credentials are held as environment secrets in the hosting platform, never in the repository. We do not deploy on Friday evenings.

9. Incident response

If we confirm a security incident affecting your data, we will notify the account administrators without undue delay, and in any case within 72 hours of confirming it. The notification will state what happened, what data was involved, what we have done, and what we recommend you do. We will not wait until we have a complete picture to tell you something is wrong.

10. Retention, deletion and export

• Your data is kept while your account is open. We do not have a retention period that quietly deletes shipment history; it is a record you may need for years, and customs and tax rules, not us, should govern how long you keep it.
• Deleting a shipment deletes its files. Removing a shipment removes its documents from object storage as well as its database records, not only the reference to them.
• You can get everything out. On request we will provide a machine-readable export of your account's data. Cost, quality and margin reports also export to CSV from inside the application at any time.
• On termination, we will export your data on request and then delete it from production, including document storage, within 30 days.
• A supplier or broker asking us to delete their details is directed to the customer who entered them, who can do it themselves immediately. We do not claim ownership of data we do not decide about, and we will support the customer in honouring the request.

11. How we operate

• Access to production systems is limited to the people who operate the service, currently a very small number, each one named on request.
• Every provider account behind the service (hosting, database, document storage, email and DNS) is protected with multi-factor authentication, as are the identity accounts they can be recovered through.
• Credentials are held in a password manager, never in the codebase or in shared documents. Application secrets live as environment secrets in the hosting platform, and the repository is checked to ensure none are committed.
• Machines with access to production are protected with full-disk encryption and lock automatically when idle.
• Storage credentials are scoped to reading and writing objects, not to administering the bucket, so a leaked application key cannot reconfigure or destroy the store.

12. What we do not have

Listed plainly, so no one has to extract it in a meeting.

• No SOC 2, no ISO 27001. Neither is planned for the current stage. We would rather answer your questionnaire directly than point at a badge we do not hold.
• No third-party penetration test to date.
• No 24/7 on-call rotation and no contractual service credits.
• No single sign-on (SAML/SCIM). Sign-in is by emailed link only. If your identity policy requires SSO, Cargease does not satisfy it today.
• No data residency options. Data is stored in the United States and on Cloudflare's network.
• No customer-managed encryption keys. Encryption at rest is the providers' own.
• No formal, audited information security policy set. This page and the runbook behind it are the honest state of it.
• No system is perfectly secure, and we will not claim otherwise.

13. Contact

Security questions, questionnaires, and requests for a data processing agreement: info@cargease.com. A real person answers, and will tell you when the answer is no.

To report a suspected vulnerability, write to the same address with what you found and how to reproduce it. We will acknowledge it within two business days. We do not run a bounty programme, and we will not pursue anyone who reports a genuine issue in good faith without accessing or altering other people's data.

Operated by Gonzalo Palazuelos, registered in Mexico as persona física con actividad empresarial. Registered domicile in Nuevo León, provided on request.

See also the privacy notice, which covers what personal data is held and the rights of the people it belongs to.