Trust & Security
Last updated: June 2026
NeuDocs handles confidential client documents for accounting, bookkeeping, and tax firms. This page lists the security controls we have actually implemented and how each one is enforced — not aspirations. Where a control is verified by automated tests, those tests run on every change before it can ship.
| Control | How it's enforced | Evidence |
|---|---|---|
| Tenant isolation | Every organization’s data is separated at the database level by Postgres row-level security (FORCE RLS), and every application query runs inside a tenant-scoped transaction. The service-role key is never used on request paths that serve end users. | Enforced by automated isolation and service-role-boundary tests that run in CI on every change. |
| Mandatory staff MFA + recovery codes | Staff cannot reach the application without passing two-factor authentication. Each staff member also gets single-use recovery codes (stored only as hashes) to self-recover if they lose their authenticator. | Enforced by the auth gate and covered by MFA and recovery-code tests in CI. |
| Malware scanning before access | Every uploaded file is scanned by a self-hosted antivirus engine before any staff member can view, approve, or export it. Infected files are quarantined and the client is asked to re-upload. Files never leave our infrastructure to be scanned. | Fail-closed scanning pipeline with automated tests; see /legal/security. |
| Encryption in transit | All traffic is served over HTTPS with HSTS, and standard security headers (frame-deny, no-sniff, referrer policy, content security policy) are applied to every response. | Security headers are covered by automated tests in CI. |
| Private storage + short-lived links | Uploaded files live in a private storage bucket with no public read path. Access is granted only through short-lived, organization-scoped signed URLs generated server-side. Links sent to clients are single-use, time-limited, and revocable. | No-public-read storage tests and single-use link tests in CI. |
| Append-only audit log + customer export | Sensitive actions are recorded in an append-only audit log that the application cannot update or delete. Customers can export their own audit log (CSV or JSON) at any time. | Append-only grants enforced in the database; export is available in-product under Audit Log. |
| Data deletion + retention | Customers can permanently delete a client’s or request’s data — including stored files — at any time, and can configure automatic retention so closed requests are purged on a schedule. | Hard-delete and scheduled-purge logic with tenant-scoped tests in CI. |
| Security-event alerts | Organization owners are emailed when sensitive events occur — a file is quarantined, MFA is reset, a recovery code is used, or data is permanently deleted. | Non-fatal alerting wired into the relevant server paths, covered by tests. |
| Supply-chain & code scanning | Every change runs typecheck, build, the full test suite, dependency vulnerability auditing, static analysis (CodeQL), and secret scanning before it can ship. | GitHub Actions workflows in the repository (CI + Security). |
| Vulnerability disclosure | We publish a machine-readable security contact and a coordinated-disclosure policy with a safe-harbor statement for good-faith researchers. | /.well-known/security.txt and /legal/vulnerability-disclosure. |
What we do not claim (yet)
We do not claim SOC 2, HIPAA, ISO 27001, . We would rather tell you exactly what is in place today than imply certifications we have not earned. We are actively working toward SOC 2 Type II and ISO 27001, in our short-term roadmap and will update this page when those certifications are achieved.
Related
Security OverviewPrivacy PolicySubprocessorsData Processing AddendumVulnerability Disclosure