Security posture — no marketing language on this page
A sale process holds the most sensitive documents your company will ever produce.
Financial statements, customer contracts, employee data, tax returns. This page describes how Bankerly protects them — exactly as the system is built, including what we have not built and what we have not certified. If a control below is a stub or a plan, it says so.
Controls in production
What protects your documents today.
Encryption at rest
Every uploaded file is encrypted with AES-256-GCM under a unique per-file data key. Data keys are themselves wrapped by a master key held outside the data store. Raw file paths are never served — all access flows through the storage layer.
Credential security
Passwords are hashed with argon2id, the current OWASP-recommended algorithm, with per-user salts. Authentication endpoints are rate-limited against brute force. Plaintext credentials are never stored or logged.
Database-backed sessions
Opaque server-side session tokens in httpOnly cookies — no stateless JWTs to leak. Signing out, changing a password, or an administrative action can revoke every active session immediately.
Signed URLs, re-checked live
Document links are cryptographically signed and expire within ten minutes. Every request also re-checks live database state — revocation, permission level, deal stage — so the token alone is never trusted and revoke is actually instant.
Default-deny access, isolated tenants
Role-based access with deny as the default: every route passes through a guard layer, and every query is scoped to the company or deal the guard resolved server-side — never to identifiers sent by the client. Cross-tenant access tests run in our automated suite.
Per-viewer watermarking, fail-closed
Every PDF a buyer views or downloads carries that viewer's name, email, and a timestamp. File types we cannot yet watermark are refused to buyers rather than served clean — the watermarking promise fails closed, not open. Revoking a buyer kills their sessions and links at once.
Append-only audit log
Sign-ins, uploads, document views and downloads, permission changes, Q&A activity, and administrative access — including our own admins entering a data room — are written to an audit log with no update or delete path in application code.
Known gaps, stated plainly
Two-factor authentication is not yet enabled (the schema is ready). Malware scanning of uploads is an interface stub pending a real scanner. Centralized alerting and a formal retention policy are on the roadmap, not in production.
Threat model
The failures we design against.
A summary of the internal threat model. Each row pairs a realistic failure with the specific controls that mitigate it — nothing listed here that the system does not do.
| Threat | Vector | Mitigations |
|---|---|---|
| Buyer document exfiltration | An NDA'd buyer forwards deal documents outside the process | Per-viewer watermarks on every view and download · append-only audit of each access · view-only mode · instant revoke · links that expire in minutes |
| Tenant crossover | A user of one company attempts to read another company's data | Tenancy resolved server-side by guards · every query scoped by the guard result · opaque IDs · automated cross-tenant tests |
| Credential stuffing | Reused or brute-forced passwords on login | argon2id hashing · rate-limited auth endpoints · revocable database sessions |
| Malicious upload | Malware or a disguised file placed in the data room | Magic-byte verification of declared types · executables rejected · size caps · files never executed or served from raw paths |
| Session theft | Cookie theft via cross-site scripting | httpOnly cookies · content security policy · React output encoding · short signed-URL windows |
| Insider access | An administrator browses seller data beyond need | Admin access is itself audit-logged to the append-only log, visible in review |
| Data-at-rest compromise | Theft of disks or backups | Per-file AES-256-GCM with wrapped keys — stolen storage without the master key is ciphertext |
Residual risks we track openly: upload malware scanning is a stub pending a real scanner, and two-factor authentication is schema-ready but not yet enabled.
Certification status
Designed to align with SOC 2. Not yet certified.
Bankerly is designed to align with SOC 2 Type II controls; certification has not yet been obtained. See the security page for our current posture and roadmap.
Certification requires a formal audit and an observation period, and we will not use the words before an auditor does. This section will state our status precisely as it changes — never before. The plan:
Control foundations
Audit logging, default-deny RBAC, encryption at rest, secrets hygiene, and this published posture — in place today.
Formal policies
Written access-control, change-management, incident-response, and vendor policies; two-factor enforcement for admins; access reviews.
SOC 2 Type I
Point-in-time audit across the Security and Confidentiality trust criteria.
SOC 2 Type II
Six-month observation window, then the Type II report. We will state the result here exactly as issued.
Responsible disclosure
Found a hole? We want the bad news first.
If you believe you have found a security vulnerability in Bankerly, email us with reproduction details. We commit to acknowledging reports within two business days, and we will not pursue good-faith researchers.
security@bankerly.aiHow this page stays honest
This page is written from the same internal security document our engineers build against, and it changes in the same commit as the controls it describes. When something here is aspirational, it is labeled a roadmap item; when it is a gap, it is labeled a gap.
Why we work this way