Security is part of how Tryso is built. This page summarises how we protect the Service and your data, and how to report a vulnerability. Our commitments to customers as a data processor are in the Data Processing Addendum.
1. How we protect the Service
- Isolation — every organization has its own database; application code resolves the organization on every request and job.
- Encryption — TLS on every public endpoint including custom store domains; secrets, API keys and OAuth tokens encrypted at rest with the application key; passwords hashed with bcrypt.
- Access control — role-based permissions inside each organization; staff access to production limited to those who need it, and logged.
- Payments — card data is entered on our payment providers' pages or secure fields and tokenised; Tryso does not store full card numbers or security codes.
- Application security — CSRF protection, strict security headers, rate limiting on sign-in and public endpoints, bot checks on public forms, signed webhooks from payment and courier providers, and dependency updates.
- Resilience — regular backups stored separately from primary servers, monitoring and an incident response process.
- Offline POS — the desktop POS stores data locally only for the signed-in organization and syncs over TLS.
2. Your part
Use strong, unique passwords or Sign in with Google, give members the least access they need, remove leavers promptly, keep your devices and browsers updated, and never share POS PINs.
3. Reporting a vulnerability
If you believe you have found a security vulnerability in Tryso, email [email protected] with:
- a description of the issue and its impact;
- steps to reproduce, affected URLs and any proof-of-concept; and
- how to contact you.
We will acknowledge your report within 3 business days, keep you updated, and tell you when it is fixed.
4. Rules for good-faith research
We will not pursue legal action against, or ask authorities to investigate, researchers who:
- test only against their own account and organization, or a test organization they created;
- do not access, modify or delete other customers' data, and stop and report immediately if they encounter it;
- do not degrade the Service — no denial-of-service, spam, load or brute-force testing, and no automated scanning that generates heavy traffic;
- do not use social engineering, phishing or physical attacks against our staff or customers;
- give us reasonable time (normally 90 days) to fix the issue before disclosing it publicly; and
- comply with the law.
Out of scope: reports from automated scanners without a demonstrated impact, missing best-practice headers without an exploit, self-XSS, clickjacking on pages without sensitive actions, rate-limit or email-enumeration issues without material impact, and vulnerabilities in third-party services (report those to the vendor).
We do not currently run a paid bug bounty, but we are glad to credit researchers who want to be named.
5. Security incidents
If we become aware of a security incident affecting personal data, we will contain it, investigate, notify affected customers without undue delay (within 48 hours for customers under our Data Processing Addendum), and notify authorities where the law requires.