Security and subprocessors

Last updated 28 September 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.

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.

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, or sign any user out on every device at once, for example after a lost laptop.

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.

Since September 2026 that scoping is also enforced by the database itself, not only by the application. Every table carrying customer data has a row-level security policy, and the application connects as a database role that cannot bypass them. A query that forgot its account filter returns nothing rather than another customer's rows: the isolation does not depend on every query being written correctly.

These policies fail closed, so a request that cannot establish which customer it belongs to sees no rows at all. Coverage is also checked automatically against the live database: a new table added without a policy fails that check. New tables are the usual way this kind of protection erodes.

5. External parties never get an account

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 rate-limited, and every file it accepts is capped in size by storage itself (see Documents);
• 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. Each file is sent to a one-time storage address created at the moment of upload, signed for that one file and its exact size, and valid for two minutes. This is separate from a supplier's upload link, which stays valid for 30 days; every file sent through that link gets its own one-time address. 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 storage itself enforces it. The file's size is part of the signed URL, so storage refuses anything larger, or of any other size, before keeping a byte. The size storage measured is checked again before the file is recorded.
• An upload is held apart until it is complete. It lands in a separate area and is moved into place only once the upload is confirmed; from then on, nothing sent to the same URL can change the recorded file. Uploads that are never completed are deleted automatically within two days.
• Storage keys are constructed by us from internal identifiers and sanitised filenames. A caller cannot craft a name that reaches another file.
• Files are never overwritten. Every upload is stored under its own new name, so a later upload cannot replace an earlier one.
• A deleted document can be recovered for 7 days. Deleting it moves the file to a private holding area, which empties itself automatically after 7 days.

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:

• The application exposes a public health endpoint that verifies it can reach its database. It is terse, reporting only healthy or degraded, because driver errors would otherwise disclose internal hostnames. An independent monitoring service checks it every 15 minutes and alerts the operator's phone when it fails.
• 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 7 days, which covers the case a code rollback cannot: a bad data change that a new deployment does not undo. Restoring creates a separate copy rather than overwriting anything, so switching to it is a separate decision. The restore was last tested on 23 September 2026: a copy was taken from an earlier point in time, checked row for row against production, and signed in to through the application, in about 20 minutes end to end. It is rehearsed again at least every six months.
• Deleted documents are recoverable for the same 7 days, so a document removed by mistake can be restored together with its record.
• Every document is also copied each night into a separate backup bucket that the application's storage credentials cannot reach, and a lock rule on it refuses to delete any copy until it is 30 days old. If files were ever destroyed outside the application, for example with a stolen storage key, they can be restored from that copy. Restoring a document from it was last tested on 8 October 2026, and is repeated every quarter. Anything uploaded since the previous night's copy is not yet covered. When you delete a document, its backup copy is removed automatically about 30 days later, and never more than 35.
• 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. The policies it follows are published.
• No 24/7 coverage, and no contractual service credits.
• Month-to-month, with no minimum term. If the service does not perform, you stop paying next month. This addresses lock-in. It does not remove the 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.

Every repository is watched by automated alerts for dependencies with known vulnerabilities and for packages found to be malicious. Alerts go to the operator by email and are reviewed as they arrive.

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.

How an incident is detected, handled and recorded is set out in the incident response policy.

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. Deleted files are held for 7 days so a mistake can be undone, then removed automatically. Their nightly backup copies are removed automatically about 30 days after the deletion, and never more than 35.
• 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. Backup copies of documents follow within at most 35 further days, and the database's restore history expires after 7 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 or in the hosting platform's secret store, never in the codebase or in shared documents. Every change to the code is scanned automatically for credentials: a commit carrying one is refused on the development machine, and every push is scanned again, across the full history, before anything is tested.
• Each credential can do only what its job needs: the storage key reaches one bucket, and the email key can send mail but not read it or change the sending domain.
• Machines with access to production are protected with full-disk encryption and lock automatically when idle.
• The application's storage credentials can read, write and delete files in one bucket, and cannot change how storage is configured. They cannot reach the nightly backup, so a leaked application key cannot destroy your documents: at worst, files uploaded since the last nightly copy.
• Outbound email is rate-limited per recipient, per customer account and in total, and the count is kept in the database, so the limits hold however many servers are running. A compromised customer account cannot turn Cargease into a bulk mailer, and customer activity cannot use up the email allowance that sign-in links depend on.
• Email from cargease.com is authenticated with SPF, DKIM and DMARC, and the domain publishes a DMARC policy telling receiving servers to quarantine mail that fails those checks. Forged invoices or "changed bank details" messages sent in our name are a common fraud in freight; this makes them much harder to deliver.
• Access to production is reviewed every quarter. See the access control policy.

12. What we do not have

• No SOC 2, no ISO 27001. Neither is planned for the current stage. We answer your questionnaire directly; we do not 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 audited information security policies. Our policies are written and published, but no third party has audited them.
• No backup with a second provider. Documents are copied nightly to a separate, locked bucket, but with the same storage provider. The database relies on its provider's own 7-day point-in-time restore.
• 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. The same contact is published in machine-readable form at /.well-known/security.txt.

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.