Security and trust
Security and trust
We are an early company. This page says plainly what exists now and what is planned, so your security and vendor-management teams can plan around it. We update it when a status changes.
Status today
| Commitment | Status | When |
|---|---|---|
| No institution data received before a signed pilot agreement, data processing agreement and security addendum | Policy, in force now | Now |
| Offer-terms teardown uses only your public offer terms, no customer data | Policy, in force now | Now |
| Written security program and named security owner | Planned | Before a pilot |
| Pilot data-entry gate: threat model, external test of the pilot data path, SSO and MFA, incident plan, insurance | Planned | Before any institution data |
| Pilot security and due-diligence pack | Planned | Before a pilot |
| SOC 2 Type I report | Planned | Before the first production contract |
| SOC 2 Type II report | Planned | After Type I; we state a date once the auditor confirms it |
| Penetration test | Planned | Before the first production contract, then yearly |
| ISO 27001 | Not planned unless a customer requires it | On request |
“Policy, in force now” means a rule we follow today that needs no system to exist. No certification or audit report exists yet.
Data custody
How Ankasum is designed to hold institution data:
- Each institution will get its own isolated data plane: in the first release, a dedicated AWS account that we operate for that institution alone.
- Our shared control plane will hold offer definitions, configuration, approvals, run metadata and totals over at least 10 customers. Smaller counts will be suppressed before anything leaves the data plane.
- Record-level screens will load directly from the institution's data plane, using a short-lived token from the institution's own identity provider. The control plane will never relay or store record-level data.
- Data, backups and model calls will stay in the country named in the contract: US data in US regions, Canadian data in Canadian regions.
- Our operators will have no standing access to institution data. Access will need time-limited elevation approved by two people, and break-glass access will need the institution's approval; every access will be logged and reported to the institution.
- Each institution will have its own encryption keys, rotated yearly and destroyed when the contract ends.
Subprocessors
We keep one register of every third party that stores, processes or can access institution information, with its service, data class, region and assurance report. Company tools that hold only business contact details are listed and marked as such.
| Vendor | Service | Data | Region |
|---|---|---|---|
| GitHub (GitHub Pages) | Website hosting | Website server logs; no institution data | United States |
| Zoho | Company email | Business contact data only; no institution data | Canada |
| Zoho (Zoho Forms) | Website contact form | What you enter in the contact form: business contact data only; no institution data | Canada |
| The full register, including product vendors, is published before the first pilot. | |||
Reporting a security issue
Email security@devankahq.com. A person reads every message sent there; it is not handled by a form service or an automated triage tool.
Please include what you found, where, and how to reproduce it. Give us reasonable time to fix it before you publish. Do not access or change data that is not yours, and do not test against any bank or credit union's systems. We will acknowledge your report and keep you informed. We do not run a paid bounty program.
Our security.txt is at /.well-known/security.txt.
Privacy
Questions about personal information we hold (website, email, business contacts): privacy@devankahq.com. See our privacy notice (draft).
Who is accountable
One founder is the named executive accountable for security and leads due-diligence and incident calls. Institutions receive that name, with a short biography, in our security pack.