Skip to content
ClosingRecord

Trust & security

Security due-diligence brief

Written for a firm's vendor review. We are not SOC 2 certified and we say so; what we offer instead is specific and checkable: the controls that exist, how each is enforced, and a plain list of what we do not have yet.

Last updated August 2026

Two status labels are used below. Live means applied and running in production infrastructure today. Built means implemented and test-verified in the codebase, going live with the pilot deployment. The encrypted data plane is live; the product service itself deploys with the pilot, and no client data exists in the system today. If your firm has a security questionnaire, send it and we will complete it.

Encryption

  • At rest (Live). Every File is envelope-encrypted with AES-256-GCM. Each File, and each privileged lane inside it, has its own data key; only the wrapped form of that key is ever stored, wrapped by a customer-managed AWS KMS key with rotation enabled. Compromise of one File's key cannot decrypt another.
  • Fail-closed (Built). In production the platform refuses to start unless encrypted storage and KMS are configured, and a boot check confirms the key is reachable and the document store enforces write-once retention. A misconfiguration stops the service; it does not silently weaken it.
  • In transit. HTTPS with HSTS on the site and product; TLS required to the database in production; the document store accepts TLS connections only.

Isolation and integrity

  • Tenant isolation (Built). Row-level security in the database on every table, with the application running as a least-privilege role and each request's identity bound to its transaction. One firm's File is not reachable from another account, and our test suite proves it at both the HTTP and SQL layers.
  • Append-only ledger (Built). Every entry is content-hashed (SHA-256) and chained to the one before it. Append-only is enforced twice: database triggers that reject any update or delete, and database privileges that were never granted in the first place. Our tests include a tamper simulation with administrator access; chain verification catches it.
  • Offline verification (Built, public). A sealed archive is verifiable on any machine with an MIT-licensed open tool: it recomputes the hash chain, the Merkle root, and every document hash with no server, no network, and no account. The file format is documented precisely enough for a third party to reimplement the verifier from scratch.
  • Write-once document storage (Live). Documents live in storage with compliance-mode object lock and a seven-year retention period. That setting is irreversible for stored objects, by design: neither we nor an attacker with our credentials can quietly rewrite a stored document.
  • Timestamps, honestly. The chain's timestamps are ours by default, and the product labels them that way. Anchoring to an independent RFC-3161 timestamp authority is implemented and test-verified but not yet the production default. We would rather tell you that than imply otherwise.

Access control

  • Role-scoped access within a File; privileged material sits in lanes visible only to the side entitled to see it, sealed with modern cryptography (X25519, ChaCha20-Poly1305), with per-lane passcodes so disclosure of one lane under legal process does not open another.
  • Optional multi-factor authentication by authenticator app (TOTP), enabled per account, with single-use recovery codes. Passkeys are on the roadmap.
  • Login lockout that works across server instances, per-route rate limiting, and standard security response headers.

Operations

  • Logging and monitoring (Built). Structured request logs that never record credentials, tokens, or document content. Alarm definitions for error rates, latency, and database health are authored in infrastructure code and go live with the pilot deployment, paging the founder. An incident-response runbook operationalizes the breach-notification commitment in the agreement we sign.
  • Backups (Live). Daily database snapshots with thirty-day retention and point-in-time recovery, a standby in a second availability zone, and deletion protection. Recovery targets: data loss under 24 hours, restore under 4 hours, with quarterly restore drills. The first drill has not yet been run; it is scheduled once the pilot infrastructure is fully deployed.
  • Testing. Over three hundred integration tests run against a real database, covering isolation, append-only enforcement, sealing and offline verification round-trips, lockout, and rate limiting. We also run documented internal adversarial security reviews; findings get fixes and regression tests, not a memo.

Data handling

  • Sub-processors. Amazon Web Services (us-east-1) for hosting, storage, key management, and email. The agreement we sign lists sub-processors and commits to keeping that list current.
  • Retention. Sealed archives and documents: seven years, write-once. Database backups: thirty days. Security logs: at least one year. Files under legal hold are exempt from every deletion path.
  • Breach notice. The agreement we sign commits to notice without undue delay of any confirmed breach affecting your data, with safeguards aligned to the New York SHIELD Act, and no sale or advertising use of your data, ever.
  • Legal process. We require valid process, notify your firm where lawful before producing anything, and produce no more than the law requires. Privilege calls stay with you. More on the security page.

What we do not have yet

  1. SOC 2 or ISO 27001 attestation. On the roadmap as we grow; this brief is the interim substitute.
  2. A third-party penetration test. Reviews to date are internal and adversarial, with documented findings and fixes.
  3. A completed restore drill. Targets are set; the first drill runs after the pilot infrastructure deploy.
  4. Cross-region backup replication. Everything is in one AWS region today.
  5. Independent timestamp anchoring as the default. Implemented, not yet switched on; the product discloses this.
  6. Passkeys. TOTP only today.

Verify it yourself

The best diligence step takes ten minutes and requires no trust in us: we send a sealed sample archive, you verify it offline on your own machine with the open-source tool, then change one byte and watch verification fail. Ask for it on a walkthrough call, or mention it when you apply on the pilot page.

Questions, questionnaires, or a data-processing agreement: JESKEL Group LLC, 718 Hard Road, Webster, NY 14580 · jesse@jeskelgroup.com · (585) 236-2340.