Customer data, protected by design — what this platform does with your regulator's questions

01The short answer

Identity documents and photographs are encrypted the moment they are uploaded; only the compliance officer or business owner can open them; every opening — and every denied attempt — is written to an audit trail; backups are encrypted separately with their own key; and logins can be restricted to approved outlet networks.

If you take one page away from this document, take this: the platform's approach is to make sensitive data unreadable by default — to a stolen laptop, a leaked backup, a mis-shared link, or anyone on staff whose job does not require it. Access is the exception, and every exception is recorded.

02Encryption of stored files

When a photograph, identity document or policy file is uploaded, the platform encrypts it before writing to disk, using the BVLT1 vault format: a randomly generated nonce per file and XSalsa20-Poly1305 authenticated encryption from the libsodium library — the same cryptographic family used by modern zero-knowledge storage products. Authenticated encryption means tampering is detected, not just reading prevented.

• On disk, a stored photo is not a photo. Opening the storage folder with a file manager shows opaque vault files, each beginning with a format marker rather than an image header.
• Decryption happens only in memory, only after the request passes the role check described in §3, and only for the duration of serving that one file.
• The encryption key lives outside the web root in a server-side secrets store, separate from the data it protects. Web requests can never read it; the weekly off-site backup copies ciphertext only.

03Who can see what

The platform separates doing the work from seeing the personal data behind it:

The practical effect for an inspection: staff can prove what they did — a customer was screened, a decision was made, a record was kept — without the raw identity scan ever appearing on their screen. The document opens only where supervision requires it, and the audit trail shows exactly which account opened which file and when.

04Accounts, sessions and network controls

• Passwords are never stored readable. They are hashed with bcrypt (PHP's standard password hashing); there is no plaintext password anywhere on the platform.
• Sessions are hardened: login cookies are HTTP-only and same-site, secure on HTTPS, and regenerated at every login and logout.
• Every state-changing action carries a CSRF token — a forged request from another site cannot act as you.
• Outlet network allow-list (optional, per company). When enabled, a correct password from an unapproved internet address still cannot log in. If an outlet's address changes (e.g. the shop's fibre line is re-provisioned), staff file a one-tap address-change request from the login page, and the owner approves it from a pending-requests queue. Approvals expire after 30 days, so a stale address never stays trusted.

05Backups and recovery

Because the archives are ciphertext, the off-site copy needs no special trust: a lost drive or a shared folder leaks nothing readable. Recovery is a restore-and-decrypt with the server-held key — and dealers should ask any provider, this one included, to demonstrate a restore, not just describe one.

06The audit trail

A running record is kept of security-relevant events, per company and per account, with timestamps:

• logins and password changes;
• each view of each sensitive document — and each denied attempt, with the requesting account;
• customer due diligence lifecycle events (created, self-filled, submitted, decided);
• document uploads, staff changes, settings changes, screening runs and AI-review usage;
• outlet address approvals and allow-list changes.

Exports from the reports module make this presentable in an inspection in minutes.

07Application hardening and tenant isolation

• Database access uses parameterised queries throughout — the injection class of attacks has no string-built doorway.
• Page output is escaped consistently (cross-site scripting defences applied at every render).
• Uploads are accepted only for whitelisted types (verified by file content, not file name), renamed to random names, size-capped, and stored outside the public web tree — files reach the browser only through the authorized, logged download path.
• Tenant isolation: every data query and every file fetch carries the caller's company identity. A dealer account is structurally unable to read another dealer's records; per-company encryption keys are on the hardening roadmap (§8) to make the separation cryptographic as well as structural.
• Optional AI assistance is off by default, enabled per company at the owner's choice (the company's own AI key, or a rate-capped shared key with per-company daily limits), and its usage is logged.

08Hardening roadmap — what we are honest about

A security page that claims perfection should be read with suspicion. These are the improvements scheduled next, stated plainly:

09How an auditor can verify all of this — live

1. The denied view. A staff account opens a customer record and clicks the ID photo: access is refused with an explanatory message. The audit trail (Reports module) shows the denied attempt, timestamped, with the account name.
2. The allowed, logged view. The compliance officer opens the same photo: it renders. The audit trail now shows the successful view alongside the earlier denial.
3. The raw file. On the server (or in a screen-share), a stored upload is opened in a hex/text viewer: ciphertext with a vault marker — demonstrably not an image on disk.
4. The backups. The backup folder shows dated encrypted archives; restoring the newest one to a scratch folder opens a customer record whose photos display for the boss role only.
5. The network gate. With the allow-list enabled, a login from an unapproved address fails after a correct password; the request-and-approve flow adds the address, and the login then succeeds.