Information Security Policy
Last updated: July 16, 2026
1. Document control
- Document title: Information Security Policy (ISP)
- Scope: the Rivo jobs platform, including user interfaces, staging and production environments, and data structures
- Version: 1.2.0
- Effective date: July 16, 2026
- Status: Approved
2. Purpose and objectives
This policy defines security standards, rules, and responsibilities for protecting Rivo’s information assets. Rivo is committed to preserving the confidentiality, integrity, and availability (CIA) of user profiles, candidate CVs, organization credit balances, transaction records, and administrative controls.
The policy aligns with the EU General Data Protection Regulation (GDPR) and the Law of Georgia on Personal Data Protection.
3. Information-security roles and responsibilities
- Service/Product Owner: accountable for final security authorization, risk assessment, and approval of production changes.
- Security & Backup Owner: responsible for testing recovery systems and executing backup plans.
- Data Protection Officer (DPO) / Compliance Lead: oversees compliance with personal-data law, conducts impact assessments, and acts as the contact for Georgia’s Personal Data Protection Service.
- Development Team: follows secure-coding principles, completes staging verification checklists, and implements database Row-Level Security (RLS) policies.
4. Access-control policy
4.1 User authentication and session management
- Session validation: authentication uses a centralized service. Cryptographic tokens (JWTs) are verified server-side on every request.
- Blocking unauthorized access: when server-side token validation fails, the user’s session is invalidated automatically and access is denied.
4.2 Route protection
Private application pages are restricted by user type and role. Administrator pages are limited to assigned system roles such as Super Admin, Admin, or Moderator under least-privilege principles. Employer pages require an authenticated, verified organization. Job-seeker pages require an authenticated individual. Users who have not completed onboarding are redirected to finish their registration profile.
4.3 Database access (Row-Level Security)
RLS is active across database tables. Access to candidate personal data, CVs, and financial credits is constrained by policies that verify the user ID or confirmed organization role. Administrative privileges are exposed only through protected administrator-authorization functions.
5. Data-protection controls
5.1 Encryption in transit
Data transferred among users, external servers, and databases is encrypted with TLS 1.3, with TLS 1.2 support.
5.2 Secure HTTP headers
The platform uses modern response headers to reduce web attacks:
X-Content-Type-Optionsprotects against MIME-sniffing.X-Frame-Options, with strict controls on authentication pages, mitigates clickjacking.Referrer-Policylimits sensitive information in referrer data.
Private pages prohibit caching and search indexing to reduce local retention of sensitive data.
5.3 CSRF protection
Application CSRF defenses are active. Trusted origins are restricted to official application domains, testing environments, and the partner payment provider.
6. Secure lifecycle and change management
6.1 Environment isolation
- Staging: an independent environment for testing changes.
- Production: a protected operating environment.
- Configuration: environment variables and production keys are never used in staging or stored in version control.
7. Subprocessors and cloud-service providers
Personal data is processed only through authorized partners that maintain recognized security standards:
- Supabase, Inc.: database, file storage, and user authentication.
- Amazon Web Services (AWS): physical database hosting in the European Union.
- Cloudflare, Inc.: application hosting, CDN, and DNS.
- Flitt: payment processing and transaction management.
8. Business logic and credit-system integrity
- Credit-balance management: purchases, deductions, and refunds run only through protected database-side functions.
- Payment validation: every payment-system webhook is checked using a cryptographic signature.
- Double-charge prevention: atomic checks protect transaction-state updates from errors caused by repeated webhook delivery.
9. Incident management and recovery
- Backups: regular daily backups and point-in-time recovery (PITR) are enabled in provider settings.
- Recovery testing: simulations and tests run only in temporary, isolated test projects, with no live connection to external email or payment services.
- Incident notification: after discovering a personal-data breach or security incident, Rivo will notify affected users and Georgia’s Personal Data Protection Service within 72 hours, in accordance with applicable law.