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, or “bank-level” security. We have not completed an independent audit or penetration test at this stage. We would rather tell you exactly what is in place today than imply certifications we have not earned. An independent penetration test and a formal compliance path are on our roadmap.
Related
Security OverviewPrivacy PolicySubprocessorsData Processing AddendumVulnerability Disclosure