A credit application is the most sensitive document in the building.
Full name, date of birth, social security number, home address, employer, income, and a bank relationship, all in one file. It is exactly the package an identity thief wants and exactly the package the Gramm-Leach-Bliley Safeguards Rule expects a dealership to protect. We built for that first.
A stolen file should be a stolen blob.
Every stored document is encrypted with AES-256-GCM before it is written. The data key is itself encrypted under a customer master key held in a managed key service, so the ciphertext and the means to read it never sit in the same place. Pulling the storage bucket gets an attacker a directory of unreadable objects.
- Envelope encryption. Per-object data keys, wrapped by a master key that never leaves the key service.
- Secrets out of the codebase. Database, mail, and API credentials are resolved at runtime from a managed secret store, cached in memory only.
- TLS in transit. Everywhere, with PGP or S/MIME added on top for lender channels that require message-level protection.
Read, not downloaded.
A credit package handed out as a file is a copy you have permanently lost control of. In SecureWebX documents are streamed into a view-only reader with the viewer's identity watermarked across the page. Printing or downloading is possible where the account allows it, but it costs a re-authentication and it is written into the record.
- Watermarked viewer. The page carries who is looking at it and when, so a photographed screen still identifies its source.
- Re-authentication to export. Print and download are separate, logged, privileged actions rather than a right that comes with viewing.
- Virus scanning. Every upload and every inbound message is scanned before it is stored or shown to a human.
- Scoped sharing. A lender sees the documents that lender was given, on a link with an expiry that can be revoked without touching the file.
Sanctions checks at submission, not in a monthly batch.
Every application is screened against the United States Treasury Office of Foreign Assets Control Specially Designated Nationals list at the moment of submission. The result is written onto the application whether it matched or not, because a documented clear screening is worth as much as a hit.
| Check | When it runs |
|---|---|
| OFAC Specially Designated Nationals | At submission, on every application, result stored either way |
| Address validation | Live on the form, against a postal record, before the step is accepted |
| Phone verification | Live on the form, checking line type and reachability |
| Malware scanning | On every upload and every inbound message, before storage |
| Automated abuse controls | After field validation, so a genuine applicant's typo never counts against them |
A log that shows when it has been edited.
An audit log anybody can rewrite is decoration. Ours is hash chained: each entry carries a digest of the entry before it, so removing or altering a row breaks every link that follows and the break is visible. There are two chains, one per application and one per company account.
Application chain
Received, screened, viewed, assigned, re-structured, shared, decided, documents added, status moved. Every event, with actor and timestamp.
Account chain
Sign-ins and failures, session duration on sign-out, password resets, user changes, permission changes, and any administrator access to the account.
Nothing is addressable by counting.
- Opaque identifiers. No database id appears in any URL. Records are addressed by tokens, so a curious visitor cannot walk from one file to the next.
- Tenant isolation. Every query is scoped to the signed-in company. There is no cross-account view for any role in the product.
- Forced first-login password change. A new user cannot keep the credential they were issued.
- Session hygiene. Signing in ends other sessions for that account, and sign-out duration is recorded.
- Support access is visible. When our team views an account to help, the account sees a standing banner saying so, and the visit is written to the account log.
- Inbound mail allowlisting. A company mailbox accepts mail only from a customer on file, a contact it wrote to first, or a partner on its list.
Small surface, few moving parts.
The application runs first party on hardware we control, with document storage in a private encrypted bucket and key management in a dedicated key service under a least-privilege identity. The web tier cannot execute shell commands at all: the capability is disabled at the process pool, not merely unused.
- No shell from the web tier. Process execution functions are disabled in the pool configuration, so an injection has nowhere to go.
- Least-privilege cloud identity. Storage and key access are granted to one narrowly scoped identity, not to the application at large.
- Content Security Policy. The public site and the application both restrict script, style, frame, and form targets rather than relying on output escaping alone.
- No advertising or tracking scripts. This website carries no advertising pixels, no session recording, and no cross-site tracking. It loads two things from outside our own servers: its typeface, and a cookieless page-view counter provided by our content delivery network, which records no personal data and follows nobody between sites.
The paperwork side of doing this properly.
- Per-dealership privacy notice. Each account publishes its own Gramm-Leach-Bliley privacy notice and terms, edited in the portal and served under its own name.
- Adverse action. Declines carry the handling a declined application requires rather than ending in a deleted row.
- Regulation Z figures. Amount financed, finance charge, total of payments, and annual percentage rate are computed on the worksheet, not estimated.
- Retention you control. Records are kept for as long as your policy requires and can be exported in full on request.
Doing a vendor security review?
Send us your questionnaire. We would rather answer it properly than have you guess from a marketing page.