Security at DocStow

Security is not a feature at DocStow — it's a precondition. Every design decision we make is filtered through one question: "would I be happy to store my own passport here?" The answer has to be yes, or we don't ship.

Encryption

At rest

Every document, every database row, and every backup is encrypted at rest using AES-256, the same standard used by banks and government agencies. Encryption keys are managed by AWS KMS in the Sydney region and never leave the secure enclave.

In transit

All traffic between your device and DocStow is encrypted using TLS 1.3, with modern cipher suites only (TLS 1.0, 1.1, and 1.2 with weak ciphers are disabled). We enforce HSTS with preload so browsers refuse to connect over plain HTTP.

Data residency

Your documents are stored in Supabase's Sydney (ap-southeast-2) region, hosted on AWS. We chose this region specifically so that New Zealand and Australian families can be confident their data is stored within the ANZ neighbourhood and is not subject to the broader data-access regimes of less privacy-friendly jurisdictions.

Database isolation & Row Level Security

DocStow runs on PostgreSQL with Row Level Security (RLS) enforced at the database layer. Every query — even if it came from a bug in our application code — is automatically filtered so that you can only ever see documents and data belonging to your own household. This is a belt-and-braces approach: even in the unlikely event of an application-level vulnerability, the database itself will refuse to return other users' data.

Authentication

• Passwords are stored as salted, one-way hashes using industry standard algorithms (bcrypt-family). We cannot see or recover your password, even internally.
• Session tokens are short-lived, signed, and rotated automatically.
• Multi-factor authentication (MFA) is on our immediate roadmap and will be available to all users at no cost.
• Brute-force protection, rate limiting, and suspicious-activity detection are enabled by default.

Access control

Access to production systems at DocStow follows the principle of least privilege. Only a small number of senior engineers have production access, all such access is logged and audited, and no engineer ever reads a customer document without explicit written consent from the customer (for example, to troubleshoot a support ticket you've opened).

Sharing & household permissions

When you invite a family member to your household, they can only access the documents you explicitly allow. Permissions are granular: view-only, upload, or full admin. Invitations expire if not accepted within 7 days, and you can revoke access instantly from your settings page.

Backups & disaster recovery

We take automated encrypted backups of all customer data multiple times per day, with point-in-time recovery available. Backups are retained in the same ANZ region and are purged automatically within 90 days of account deletion. We test our restore procedure regularly.

Secure software development

• All code changes go through peer review before being deployed to production.
• Automated dependency scanning (Dependabot / GitHub Security Advisories) alerts us to any known vulnerabilities in our libraries.
• Static analysis and secret scanning run on every pull request.
• Infrastructure is defined as code and version-controlled; no manual changes in production.
• All production secrets are stored in a managed secret store, never in source code.

No AI training on your data

We do not — and will never — use your documents to train machine learning models. When you opt in to our AI-powered metadata extraction features, the content you choose to process is sent to OpenAI under a zero-retention agreement and is deleted within 30 days. You can turn AI features off at any time.

Responsible disclosure

If you believe you've found a security vulnerability in DocStow, please report it confidentially to security@docstow.com. We ask that you give us a reasonable window to investigate and fix the issue before any public disclosure. We gratefully acknowledge responsible reporters and are working on a formal bug-bounty program.

Incident response

In the unlikely event of a security incident that affects customer data, we will notify affected users and the New Zealand Office of the Privacy Commissioner (and other relevant authorities) as required by the Privacy Act 2020 and applicable international laws. Our incident-response plan is rehearsed regularly.

Roadmap

On our security roadmap: multi-factor authentication for all users, SOC 2 Type II audit, customer-managed encryption keys for Premium customers, and an ongoing bug-bounty program.

Questions?

Security questions, audits or vendor reviews? Email security@docstow.com and we'll reply promptly.