How we protect your agency's data
Client lists, passport copies, supplier costs and payment records are sensitive. This page describes the controls that are in place today — and is explicit about our multi-layered isolation architecture.
TLS 1.3 & AES-256 Encryption
Enforced across all network requests & databases
Encrypted in transit and at rest
Every request runs over HTTPS with TLS 1.2 or better; HTTP is redirected and HSTS is enforced. Data at rest is encrypted by our infrastructure providers, and uploaded documents live in private buckets that are never publicly listable.
Row-level tenant isolation
Every business record carries the identity of the agency that owns it, and PostgreSQL row-level security enforces that boundary inside the database — not just in application code. A query for another agency's data returns nothing, even if application logic were wrong.
Two-factor sign-in by default
Signing in from an unrecognised device sends a six-digit code to your registered email that you must enter to continue. Codes are single-use, expire quickly, and are stored only as a hash — we cannot read them. A verified device stays trusted for 20 days.
Role-based access
Owners, managers and staff get different permissions, and the platform administration console is a separate role that agency accounts can never reach. Invited staff see only their own agency's workspace.
Managed cloud infrastructure
The application runs on Vercel, the database on Supabase in the AWS Singapore region, documents in Cloudflare R2, and transactional email through Brevo in the EU. Each provider maintains its own independent security certifications.
Audit logging
Password checks, one-time codes, device trust changes and record edits are written to an append-only activity log with timestamp, IP and device. It is what we read first when investigating anything.
Account protection
Passwords are never stored in readable form. Authentication is handled by Supabase Auth, which stores a salted bcrypt hash — nobody at TourVilo can retrieve or see your password, and a database dump would not reveal it.
- A minimum password length is enforced at sign-up, and weak or breached passwords are rejected.
- Sign-in attempts are rate limited per IP address, so an attacker cannot brute-force an account.
- Every sign-in, failed attempt and one-time code is recorded with its IP, browser and approximate country.
- You can revoke a trusted device at any time from your profile, which forces a fresh one-time code on the next sign-in.
- Password reset links are single-use and short-lived, and we never email you your existing password.
Monitoring
We keep an internal monitoring console showing live traffic, failed sign-in volume, email delivery success and per-tenant usage, all measured from our own database rather than a third party.
What we do not have yet: an external uptime prober, an application error-tracking service, and paged on-call alerting. Those are named on the roadmap below rather than implied here. We would rather tell you the gap than claim a monitoring maturity we have not built.
Backups and recovery
Database backups are managed by Supabase on our behalf, with retention and point-in-time recovery determined by our hosting tier. Uploaded documents are stored in Cloudflare R2, which replicates objects across its own infrastructure.
We have not yet completed a documented full-restore drill. Until we have, we will not claim a recovery time objective we have not measured. This is scheduled work, not an oversight we are hiding.
Incident response
If we detect or are told about a security incident:
- Contain. We revoke the affected credentials or sessions and, if necessary, take the affected surface offline.
- Assess. We work out what was accessed, by whom and when, using the audit log.
- Notify. Where personal data was affected, we notify the agencies involved without undue delay and, where GDPR applies, the relevant supervisory authority within 72 hours of becoming aware.
- Remediate and report. We fix the cause and give affected customers a written account of what happened and what changed as a result.
We will tell you about an incident that affects your data even when we are not legally obliged to.
Responsible disclosure
If you find a vulnerability, please report it to security@tourvilo.com before disclosing it publicly. Include enough detail to reproduce the issue.
Our commitment: we acknowledge every report within two business days, keep you updated on the fix, credit you if you would like to be credited, and will not pursue legal action against researchers acting in good faith under these terms.
What we ask: do not access, modify or delete data belonging to any agency other than a test account you created; do not run automated scanners or load tests against production; give us reasonable time to fix the issue before going public.
We do not run a paid bug bounty programme at this stage.
Compliance roadmap
We build to GDPR principles — lawful basis, data minimisation, purpose limitation, and the rights to access, correct, export and delete. Our processing terms are set out on the Data Protection page, along with the full list of subprocessors.
TourVilo is not itself SOC 2 or ISO 27001 certified. Our infrastructure providers hold their own certifications, but that is their compliance posture and not ours — a distinction some vendors blur. Independent certification is on our roadmap; we will publish the report when we have one rather than before.
Security contact
Security reports: security@tourvilo.com
Everything else: support@tourvilo.com
TourVilo (Pvt) Ltd · Kandy, Sri Lanka · Mon–Sat 9:00–18:00 Sri Lanka time (GMT+5:30)