This overview describes current engineering controls; it is not a SOC 2 report, penetration-test attestation, BAA, data-residency promise, or guarantee that incidents cannot occur.
1. Application and access controls
- Better Auth manages password credentials, verified email, session expiry, reset links, and sign-in rate limits.
- The browser reaches product data through the Next.js server boundary; FastAPI rechecks user, workspace, role, ownership, state, and plan access.
- Workspace members, vendors, reviewers, recipients, and administrators receive different scoped access.
- API keys and bearer-style vendor or delivery tokens are hashed or otherwise protected at rest where the workflow supports them.
- Cross-origin request checks, secure cookie settings in production, content-security policy, and bounded link expiry reduce common web risks.
2. File and storage safeguards
- Production object storage is private; application authorization or bounded delivery access is required to retrieve files.
- File size, declared type, and content signatures are validated before expensive processing.
- Production uploads are scanned with ClamAV and fail closed when the required scanner is unavailable.
- Documents, remediation results, Exchange returns, reviews, approvals, and evidence use versioned records so later files do not silently inherit earlier decisions.
- Deletion uses a durable retry ledger so temporary object-storage failures remain visible until resolved.
3. Processing and provider controls
Long-running remediation runs outside request processes with bounded execution and terminal success or failure states. Outbound site fetching rejects local, private, metadata-service, and otherwise unsafe addresses. Webhook delivery is scoped and retried with destination safety checks. Providers are limited to defined roles described on the Subprocessor List.
4. Monitoring, support, and privacy
Application health, background jobs, failed storage deletion, billing events, and operational errors are monitored. Sentry, when configured, has default PII capture disabled and event scrubbing for credentials, cookies, email, network addresses, and private URLs. Logs must not contain documents or secrets. Account-specific support sessions are time-limited, display an in-product warning, require a recorded reason, and create audit events.
5. Availability, backup, and recovery
Production health and readiness checks cover the web application, API, database, queue, storage, malware scanner, and PDF validator dependencies. Backups are access-restricted, rotated, and designed to cover database and private object storage together. No public service-level agreement or recovery objective applies unless a signed order states one.
6. Customer responsibilities
- Use unique credentials and promptly remove people who no longer need access.
- Protect API keys, share passwords, vendor URLs, intake URLs, and delivery links.
- Upload only data needed for the workflow and avoid unsupported regulated information.
- Review visibility before publishing and revoke links that are no longer required.
- Keep endpoint software, browsers, integrations, and webhook receivers secure.
7. Report a vulnerability or incident
Use the security contact route with a concise description, affected URL or feature, and safe reproduction steps. Do not access another customer's data, disrupt availability, perform denial of service, or include credentials or exploit payloads in the public form. We will provide a protected follow-up channel if sensitive evidence is needed.
8. Procurement evidence
We will answer security questionnaires based on current evidence. DocAccessible does not currently claim SOC 2 Type II, SAML SSO, a signed BAA, US-only data residency, or self-hosted customer deployment. Any future claim will appear here only after it is supported and approved.