Security policies

Adopted 23 September 2026 · Revised 25 September 2026

Owner of all three policies: Gonzalo Palazuelos, operator of Cargease. Each is reviewed at least once a year, and whenever the system or a provider changes in a way that makes a line untrue.

1. Backup and recovery

What is protected, and how

How a restore is done

1. A new copy of the database is created from the chosen point in time. Production is never restored in place, so the decision to switch is taken after checking the copy.
2. The copy is checked against production table by table (row counts and the most recent change in each table) and confirmed to still carry every tenant-isolation policy.
3. The application is run against the copy and signed in to, to confirm the data is usable and not just present.
4. Only then is the recovered data brought back into production, and the copy is deleted.

Testing

Last tested 23 September 2026: a point-in-time copy was created, verified row for row against production, and signed in to through the application. End to end it took about 20 minutes. The restore is rehearsed again at least every six months, and after any change to the database provider or plan.

Limits

• Nothing older than 7 days can be recovered from the database. A deleted document's file can be recovered from the backup copy for about 30 days, but without its database record once the 7 days have passed.
• The backup copy is taken nightly, so a file uploaded since the last copy is not yet covered.
• There is no copy with a second provider. The document backup is kept with the same storage provider, and the database relies on its provider's own durability.

2. Incident response

How an incident is noticed

External monitoring

An independent service checks every 15 minutes that the application is up and can reach its database, and alerts the operator's phone when it cannot.

Reports

From customers, or from anyone who finds a vulnerability, at info@cargease.com. A vulnerability report is acknowledged within two business days.

Provider notices

From the hosting, database, storage and email providers.

Dependency alerts

Every source repository is watched for dependencies with known vulnerabilities and for malicious packages, with alerts emailed to the operator.

What happens

1. Triage

Against a written runbook: is it our change, a provider outage, or the database? Provider status pages are checked before our own code.

2. Contain

Depending on the cause: roll back to the previous version; rotate the affected credential (sign-in secret, database password, storage key or email key); remove a user; or revoke a supplier's upload link. Rotating the sign-in secret signs every user out at once.

3. Recover

Using the restore procedure above where data is affected.

4. Tell the customer

For an outage affecting their shipments, as soon as it is confirmed, and before they notice where possible. For a security incident affecting their data, without undue delay and within 72 hours of confirming it, stating what happened, what data was involved, what has been done, and what they should do.

5. Write it down

Every incident gets a short record: timeline, cause, fix, and what changes so it does not recur. A customer affected by an incident can ask for that record.

Limits

There is no 24/7 on-call rotation. Alerts reach one person. Response is fast during working hours in Mexico (Central Time) and best effort outside them.

3. Access control

Who has access to production

One person: the operator. No contractor, agency or other third party holds access to production systems or customer data.

How that access is protected

Multi-factor authentication

On every account behind the service: hosting, database, document storage and DNS, email delivery, source code, uptime monitoring, and the identity accounts they can be recovered through.

Credentials

Kept in a password manager that is itself protected by multi-factor authentication, or only in the hosting platform's secret store, from which they cannot be read back. They are never kept in the codebase or in shared documents. Every commit is scanned for credentials, on the development machine before it is made and again on every push.

Scope

Each credential is scoped to its job: the storage key reaches one bucket, and the email key can send mail but cannot read it or change the sending domain.

The operator's computer

Full-disk encryption, and it locks automatically when idle.

Least privilege inside the system

• The application connects to the database as a restricted role that cannot bypass tenant isolation. The unrestricted owner role is used only for schema changes, recovery, and the operator's administrative scripts (setting up an account, changing its plan, exporting its data).
• The application's storage key can read, write and delete files in the production bucket only. It cannot change how storage is configured, and it cannot reach the backup bucket.
• Production secrets live only in the hosting platform's secret store.

Customer users

• No self-service signup. Users are added by an administrator of the customer's own account, or by us when the account is set up.
• Three roles: Administrator, Operator, Viewer. A Viewer is blocked from every action that writes, on the server, not only in the interface.
• Removing a user from the team page ends their access.
• Suppliers, brokers and carriers never get an account. They receive a single upload link, scoped to their own documents on one shipment, that expires after 30 days.

If anyone joins

Anyone given production access gets their own named accounts, with multi-factor authentication required from the first day, and only the access their work needs. Shared logins are not used. On leaving, their access is removed the same day and any credential they could have seen is rotated.

Review

The list of accounts with production access, and the multi-factor state of each, is reviewed every three months.