Trust
Security at YouInc
YouInc handles sensitive financial data, so the security model starts with least-privilege access, read-only bank connections, per-user data separation, clear export controls, and founder-accountable support. This page describes today's posture honestly and marks what is still planned.
Last updated: 5 July 2026
How sign-in works
- Accounts use email + password sign-in, and new signups must confirm their email address before the workspace unlocks.
- Every workspace is isolated at the database level by row-level security, so you only ever see your own tenant's data — never another customer's.
- The app is served over HTTPS and sessions are held in secure, HTTP-only cookies bound to the YouInc origin.
How bank data is handled
- Bank connections run through Akahu and are read-only. YouInc never receives or stores your online-banking password.
- You choose which accounts to share, and you can revoke access through Akahu at any time.
- Connected data is used only to build the ledger and dashboard views you ask for.
- The demo uses sample data on a separate store and never exposes real customer data.
Data separation
YouInc is built as a multi-tenant system where each user's ledger is scoped to their own tenant, and database row-level security is designed so a query can only reach rows the signed-in user is a member of. This isolation model has not yet been independently audited, and a third-party review is on the roadmap below.
Data protection principles
- Collect the minimum data needed to run the product and support the user.
- Keep financial data separated per user and never pool ledgers for advertising or resale.
- Make ledger export and exit paths first-class, not an afterthought.
- Treat any support access to financial data as sensitive and use it only to help the user or operate the service.
Backups
Production data is backed up on a scheduled basis so it can be restored after a failure. Restore drills, retention windows, and encryption-at-rest details will be documented as part of the security roadmap below.
Incident response
Security reports and suspected incidents are reviewed directly by the founder. Confirmed issues are triaged, patched, communicated to affected users where appropriate, and recorded on the status page and changelog when they materially affect customers.
Reporting a vulnerability
Please report suspected vulnerabilities to hamishapps@gmail.com with "security" in the subject line. Include the affected page or endpoint, reproduction steps, impact, and whether any data may have been accessed. Please do not publicly disclose an issue before it is fixed. A dedicated security inbox and a formal disclosure policy are on the roadmap below.
Security roadmap
- Publish infrastructure and data-flow diagrams at a non-sensitive level.
- Stand up a dedicated security contact address and a written vulnerability disclosure policy.
- Document backup, restore, encryption, and access-review procedures in detail.
- Commission a third-party security review before scaling beyond early users.