Trust & security
Built like it holds a business's tax returns. Because it will.
Every lender who engages us has to review us as a third party. This page answers the first questions that review asks, honestly — including what is not finished yet.
Compliance status
- SOC 2: SOC 2 Type I in preparation — target Q1 2027. Scope: Security, Confidentiality and Processing Integrity.
- Penetration testing: External penetration test scheduled before the first Tier 1 lender engagement.
- Insurance: Cyber and E&O coverage being bound.
Until a SOC 2 report exists, the security package (below) carries our information security program summary, a completed questionnaire, the architecture overview, the subprocessor register and our incident response and continuity summaries.
Data classes
Everything we hold is classified, and the class decides where it may go.
| Class | Examples | Handling |
|---|---|---|
| Restricted | IRS transcripts, tax returns, bank statements, account and routing numbers, SSNs and EINs, aggregator tokens | Encrypted per engagement on top of storage encryption. Never in logs, analytics or email. Seen by a language model only after identifiers are removed. Viewing requires a fresh sign-in check, and every view is recorded. |
| Confidential | General ledger, adjustment schedules, reports, deal terms, borrower identity | Encrypted at rest, scoped to the engagement's tenant, logged by record ID only. |
| Internal | De-identified benchmarks, marketing inquiries | Staff only. |
| Public | This site, the methodology, the fictional demo file | — |
We ask for less
A QoE is about the business. Intake asks for business returns, business bank statements, the general ledger and a business Form 4506-C. If a personal return, personal financial statement or consumer credit report is uploaded, it is flagged as not required, excluded from processing, and offered for deletion.
Encryption and disposal
- TLS 1.2 or later on every connection, with HSTS on every QoE host.
- Documents stored in AWS S3 with KMS encryption, public access blocked, versioning on.
- Restricted fields encrypted with a data key unique to each engagement. Disposal destroys that key, which makes the engagement's restricted data unrecoverable everywhere it was copied — including backups.
- Issued reports held in write-once storage.
Sign-in and access
- Multi-factor sign-in is mandatory for every account. Staff sign in with passkeys. Lenders can use their own single sign-on.
- Viewing restricted excerpts, downloading a report and every administrative action require a sign-in no older than five minutes.
- Borrowers on a lender engagement can upload documents and see their checklist and status — nothing else. They cannot see findings or the report.
- No standing production database access. Emergency access requires a written reason, alerts immediately and expires in an hour.
Tenant isolation
Each lender is a separate tenant, and isolation is enforced by the database itself — row-level security — not only by application code. A test that one tenant cannot read another's rows runs on every change.
No third-party scripts in the portal
The portal, where tax data is displayed, loads no analytics, pixels, tag managers, chat widgets or session replay. Its content security policy forbids scripts from any other origin; the bank-connection widget is the single exception, and only on the one page that uses it. This public site uses cookieless analytics at most, and never on the demo.
Uploaded documents
Every upload is treated as hostile until scanned: file-type verification, malware scanning, removal of scripts and embedded content from PDFs, detection of hidden text, and checks for signs of editing. The IRS transcript is the cross-check a seller cannot alter.
Logging and monitoring
Application logs are redacted at the logger. Security-relevant events — sign-ins, every view of restricted data, downloads, role changes, engagement declines, report issuance — go to a tamper-evident, append-only event log kept for seven years.
Report verification
Every issued report is digitally signed, watermarked with its recipient, and carries a verification ID and code. Anyone holding a copy can check it at /verify, which returns only whether it is genuine, when and to whom it was issued, and whether it is current, superseded or revoked.
Incident notification
Lender clients are notified within 24 hours of our determining that an incident affects their data or disrupts service.
Subprocessors
Updated 2026-10-11. Lender administrators are notified when this list changes.
| Vendor | Purpose | Data | Security reports |
|---|---|---|---|
| Railway | All compute (marketing, portal, API, worker, scanner, engine), Postgres, Redis, TLS termination | Business-confidential data; restricted data only as ciphertext at rest and in transit to the services | SOC 2 Type II and SOC 3; DPA available(source: Railway Trust Center)src |
| Amazon Web Services | Document storage (S3), key management (KMS), backups | Business-confidential and restricted data, encrypted | ConfirmConfirming |
| Cloudflare | Turnstile bot check on public forms; optional cookieless web analytics on the marketing site only | Form-submission metadata; no financial data | ConfirmConfirming |
| Identity provider (WorkOS or equivalent) | Single sign-on, multi-factor authentication, passkeys | User identity | ConfirmConfirming |
| Anthropic | Classification and drafting of prose — never figures | Redacted business-confidential data | Confirm terms; zero data retention requestedConfirming |
| Plaid | Bank connectivity | Bank data (restricted) | ConfirmConfirming |
| Intuit | QuickBooks Online API | General ledger (business-confidential) | ConfirmConfirming |
| IVES participant vendor (to be selected) | Form 4506-C transcript retrieval | IRS transcripts (restricted) | SOC 2 and IVES participant status requiredConfirming |
| Postmark or AWS SES | Transactional email | Contact data only | ConfirmConfirming |
| E-signature vendor | Engagement letters and reviewer sign-off | Names and signatures | ConfirmConfirming |
| Stripe | Invoicing | Billing contacts; card data stays with Stripe | ConfirmConfirming |
| Sentry | Error tracking with server-side scrubbing | Scrubbed telemetry | ConfirmConfirming |
| Log platform | Application logs | Redacted logs | ConfirmConfirming |
| Compliance automation platform | Evidence collection | Configuration metadata | ConfirmConfirming |
Responsible disclosure
If you believe you have found a security vulnerability in any Ikigai QoE system, email security@qoe.ikigai.properties. Our contact details are also published at /.well-known/security.txt.
- Give us reasonable time to fix the issue before disclosing it publicly. We acknowledge reports within two business days.
- Test only against your own accounts. Do not access, change or delete data that is not yours, and stop and tell us if you encounter any.
- No denial-of-service testing, social engineering, or physical attacks.
- We will not pursue legal action against research done in good faith under this policy.
Our remediation targets: critical within 7 days, high within 30, medium within 90.
Request our security package
For lenders conducting vendor due diligence. We review each request by hand and send the package to verified lender contacts.