The minimum security baseline for platforms that store client files

A client file gathers in one place everything a third party would need to impersonate someone: official ID, CURP (Mexican population registry key), RFC (tax ID), tax status certificate, proof of address and, for legal entities, articles of incorporation and powers of attorney. KYC and AML compliance platforms store thousands of these files. Below we share the controls we consider the minimum floor, not the ceiling, based on what we apply and periodically review in our own systems.

1. Access: least privilege and per-client isolation

The most expensive mistake is usually not a sophisticated attack but a user seeing someone else's files.

• Every database query must be scoped to the user's organization, and that restriction must live on the server or in the database rules, not in the interface. Hiding a button is not a control.
• A record's organization identifier must not be editable after creation. If a user can edit that field, they can move data from one client to another.
• Roles must have explicit permissions: whoever captures data does not necessarily approve, and whoever approves does not necessarily manage users or change roles, including their own.
• Every backend route must declare its authentication mechanism. It is worth enumerating them periodically to confirm none was left open, and documenting the ones that are public by design as such.
• Service credentials with full access are used only in server processes and never as loose files; in the cloud, the service's own identity is preferable.

2. Encryption and file handling

• Encryption in transit on every connection, with HSTS, and encryption at rest. The major cloud providers offer it by default, but you need to confirm it also covers backups and exports.
• Files in private storage. For downloads, short-lived signed URLs, never permanent public links.
• Validate files by their content, not just their extension: that a PDF really is a PDF, that it is not protected or damaged, and with limits on size and page count.
• Generic error messages to the outside, with a request identifier to trace the detail internally. An error that reveals internal paths or database queries is useful information for an attacker.

3. API keys and webhooks

Integrations are the door through which the most data leaves a platform, so they deserve their own rules.

For API keys:

• Store only a hash of the key and show it in full only once, when it is created.
• Use a recognizable prefix so secret-scanning tools can identify it if it ever gets published in a repository.
• Issue one key per integration, individually revocable and with a last-used record.
• Compare secrets in constant time and apply rate limits so keys cannot be brute-forced.
• Keep the platform's secrets in a secrets manager, not in files on servers or in the code, and rotate them when someone leaves the team or exposure is suspected.

For webhooks:

• Sign every delivery, for example with an HMAC over the body and a timestamp, so the receiver can verify origin and integrity, and reject messages with old timestamps.
• Verify a signature or token on every webhook the platform receives. An unverified endpoint lets anyone trigger processes with fake data.
• Send the minimum: identifiers and status, not the full file. The receiver fetches the detail with its own credentials.

4. Audit trail and retention

• Record who viewed, downloaded, modified or approved each file, with date and origin. The log must be append-only and platform users must not be able to edit it.
• Define retention by data type. The LFPIORPI (Mexico's anti-money-laundering law) requires keeping identification information and documentation for a minimum period; since that period has been subject to amendments, we recommend confirming the current one with your legal team. Meanwhile, personal data protection law asks that data not be kept longer than necessary. Both obligations coexist and should be written down in a policy.
• Technical logs should not contain personal data; if they unavoidably do, their retention should be short and automatic.
• Backups are part of the retention policy: deleting a file in production while keeping it indefinitely in a backup is not deleting it.

The useful question is not whether the platform is secure, but what happens when a key leaks, a user lands in the wrong organization or a vendor has an incident. Each control on this list answers one of those scenarios.

5. Vendors and language models

Processing client files with OCR and language models adds vendors and new risks.

• Keep an inventory of the vendors that touch client file data: cloud, OCR, language models, email, electronic signature.
• With language models, use enterprise contracts or plans whose terms exclude using the data for training, and review the vendor's retention and processing region.
• Send the model only what the task needs.
• Treat document text as data, not as instructions: a document may contain text designed to alter the model's behavior. The model's output is validated before being stored and never triggers actions on its own.
• Reflect in the privacy notice the use of third parties that process data on the platform's behalf.
• Self-host the libraries that run in the browser alongside the documents, or load them with integrity verification.

These principles are the foundation on which we build Loony: each client file lives in a versioned archive isolated per organization, and every extracted data point keeps the page and line it came from, which also makes it easier to audit who saw what and when.

If you want to review your platform's controls using this list as a starting point, Write to us.