Security practices

Governance

Douglas Doehrman is the application owner, system administrator, and information-security contact. Security controls, access, providers, and retention decisions are reviewed at least annually and after material system changes.

Access control

• Public registration is disabled; users must be explicitly invited.
• Each person receives an individual account and a defined owner or accountant role.
• Private financial access and Plaid Link require a password plus a time-based authenticator code; trusted-device bypass is disabled.
• Bank connection, receipt approval, and other sensitive mutations require an authenticated owner.
• Workspace authorization is enforced by both the application server and forced PostgreSQL row-level security.
• Administrative access to critical infrastructure also requires multi-factor authentication.
• Access is reviewed quarterly and removed when it is no longer required.

Encryption and secrets

• Production traffic uses HTTPS and modern TLS.
• Structured financial data is stored in an encrypted managed PostgreSQL service.
• Receipt and statement files remain in private object storage.
• Plaid access tokens are encrypted with AES-256-GCM before database storage.
• Production secrets are stored in deployment secret managers and are not committed to source control.

Application and data safeguards

• Security headers restrict scripts, framing, referrers, browser permissions, and outbound connections.
• Runtime database credentials are non-administrative, cannot bypass row-level security, and receive narrow grants.
• Original receipt and bank-import evidence is preserved with audit provenance.
• Plaid webhooks are cryptographically verified before processing.
• Financial imports remain review evidence and cannot automatically post accounting entries.

Secure development and vulnerability handling

Source changes are version-controlled and must pass automated tests, type checks, linting, and a production build before release. Dependency advisories are checked automatically. Critical and high-severity findings are prioritized under documented remediation deadlines, while supported runtime and dependency versions are reviewed on a recurring schedule.

Incident response

Suspected security incidents are triaged by the security owner. The response process includes containment, credential or token revocation, evidence preservation, impact assessment, recovery, and notification to affected providers or people when appropriate or legally required.

Report a concern

Report suspected vulnerabilities, unauthorized access, or privacy concerns to doehrman@gmail.com. Please do not include passwords, bank credentials, or complete financial account numbers in email.