Security Policy

Reading note. This Policy explains how WiseWave Limited secures the Tirvea platform. It covers security practices only. How your personal data is used is in the Privacy Policy (/legal/privacy); biometric and verification specifics are in their own policies; to report a vulnerability, see the Vulnerability Disclosure Policy (/legal/vulnerability-disclosure).

1. Purpose

Purpose. To describe the information-security principles, technical safeguards, and operational controls WiseWave Limited applies to protect the Tirvea platform and the data it processes. This Policy supports, and is part of, your agreement with WiseWave Limited (Terms of Service, /legal/terms).

2. Scope

Purpose. To state what this Policy covers. It covers the security of the Tirvea application, its APIs, and the managed cloud services it depends on. It does not set out how personal data is used (Privacy Policy, /legal/privacy), the verification of identity or photos (Identity Verification and Photo Verification policies), or content moderation (Trust and Safety Policy). It applies to WiseWave Limited and its service providers acting on its behalf.

3. Security Principles

Purpose. To state the principles that guide our controls.

Least privilege. Components and credentials are granted the minimum access they need; for example, browser liveness credentials are scoped to a single AWS action and expire in minutes.
Defence in depth. Multiple layers apply: authenticated sessions, explicit authorization, signed webhooks, rate limiting, input validation, and security headers.
Secure by default. Sensitive features stay off until explicitly enabled and permitted; secrets are never logged; error responses expose machine codes, not internal detail.
Data minimisation in logs. Identifiers such as IP and user agent are stored only as salted hashes; logs never contain tokens, credentials, or personal principals.
Provider responsibility, clearly bounded. Where a control is delivered by a provider (for example encryption at rest or backups), we say so rather than implying we operate it ourselves.

4. Identity and Access Management

Purpose. To explain how identities and privileged access are managed. User identity is anchored to Supabase Auth; a single Supabase user id is the principal across the app. Access to protected resources is governed by explicit role-based permissions; there is no implied role hierarchy, and each permission is checked directly. For cloud access, the runtime uses least-privileged credentials: AWS access is limited to assuming one narrowly-scoped role for liveness streaming and to region-pinned server calls, with collection administration excluded. [Legal review required before publication - confirm the administrative-access model for operators.]

5. Authentication

Purpose. To explain how users are authenticated. Authentication is handled by Supabase Auth; Tirvea does not store account passwords. Sessions are established through Supabase and verified on every request by validating the session token's signature, expiry, and revocation status. The platform accepts both browser session cookies and bearer access tokens for API clients; when both are presented they must resolve to the same user. Sensitive authentication actions (such as sending or verifying one-time codes) are rate limited, and authentication events are recorded with hashed IP and user-agent values.

6. Authorization

Purpose. To explain how access decisions are made after authentication. Every protected API route requires a valid session and, where relevant, a specific permission tied to the user's role. Requests without a session receive 401; authenticated requests lacking the required permission receive 403. Accounts under restriction are blocked at a single choke point with a 403 account_restricted response. Authorization is explicit and enumerated, not inferred.

7. Infrastructure Security

Purpose. To describe the platform infrastructure and its protections. Tirvea runs as a serverless web application on managed hosting, with a managed PostgreSQL database and object storage (Supabase), and integrates Stripe and AWS. All traffic is served over HTTPS/TLS, enforced by HSTS (two-year max-age, includeSubDomains, preload). Responses set hardening headers (X-Frame-Options: DENY, X-Content-Type-Options: nosniff, Referrer-Policy, Permissions-Policy) and suppress the framework's identifying header. A Content-Security-Policy header is not currently configured and is under review. Backups and point-in-time recovery are provider-managed. [Legal review required before publication - confirm CSP and backup arrangements.]

8. Cloud Security

Purpose. To describe how cloud provider access is secured. AWS is accessed with SigV4-signed requests over HTTPS, pinned to approved EU regions (eu-west-1); requests targeting a non-approved region are refused. Browser liveness uses AWS STS AssumeRole to issue short-lived, single-action credentials; the assumed role permits only starting a liveness session, and the credentials expire within minutes. Server-side face operations are confined to an adapter that treats provider references as opaque and never logs images, reference handles, or scores. The AWS face-collection layer is dormant by default and gated behind configuration, a legal gate, and an internal allowlist. [Legal review required before publication - confirm the cloud-provider configuration in production.]

9. Application Security

Purpose. To describe safeguards in the application layer. Inputs are validated (schema validation) before use. Webhooks from Stripe, Resend, and Supabase are signature-verified over the raw body with timing-safe comparison, and processed events are de-duplicated to resist replay. Sensitive actions are rate limited. Billing operations use idempotency keys, and an idempotency-replay mechanism prevents duplicate side effects. User media is delivered through signed, short-lived URLs, and push notifications validate their destination and never carry message content. The public API is exposed on a versioned surface.

10. Data Protection

Purpose. To describe how data is protected technically. Data is protected in transit by TLS across all traffic, including to Supabase, Stripe, and AWS. Encryption at rest is provided by the underlying platforms (Supabase database and storage, Stripe, AWS). In application logs and audit records, identifiers such as IP and user agent are stored only as salted hashes, and sensitive material (tokens, credentials, verification images, biometric references, similarity scores) is never logged. How long data is kept, and how it is deleted, is set by the Data Retention Policy (/legal/data-retention); how it is used and your rights over it are in the Privacy Policy (/legal/privacy). [Legal review required before publication - confirm the at-rest encryption position per provider.]

11. Logging and Monitoring

Purpose. To describe logging, monitoring, and audit. Operational logs record safe machine codes and reasons only, never tokens or personal principals. Append-only audit trails record privileged and safety-relevant actions, authentication events (with hashed IP and user agent), and verification events. A health endpoint reports database, configuration, and billing status, and a monitoring runbook defines dashboards and alerting for operators. External error-monitoring or security-information-and-event-management tooling, where used, is operator-provisioned. [Legal review required before publication - confirm the production monitoring and alerting stack.]

12. Incident Response

Purpose. To explain how we handle security incidents. We investigate suspected security incidents, contain and remediate them, and, where a personal-data breach meets the legal threshold, we notify the competent supervisory authority and affected users as required by applicable law (including the GDPR), in cooperation with our providers. Our detective controls (audit trails, health checks, rate-limit and authentication signals, and provider alerting) support timely detection and response. Vulnerability reports are handled under the Vulnerability Disclosure Policy (/legal/vulnerability-disclosure). [Legal review required before publication - confirm the incident-response runbook, roles, and notification timelines.]

13. Third-Party Providers

Purpose. To identify the providers we rely on for security-relevant functions. Tirvea relies on Supabase (authentication, database, storage), Stripe (payments and identity verification), Amazon Web Services (Rekognition and STS for face liveness, EU region), Resend (transactional email), and Upstash (rate-limit store). These providers process data on our behalf as described in the Privacy Policy (/legal/privacy); certain security controls, including encryption at rest and backups, are delivered by them. We select providers on the basis of their security posture and bind them by contract. [Legal review required before publication - confirm the provider list and the data-processing agreements.]

14. User Responsibilities

Purpose. To explain your part in keeping your account secure. Keep control of the email address, phone number, or third-party sign-in you use to access Tirvea, and of the device you use. Do not share access to your account, and sign out on shared devices. Tell us promptly at info@tirvea.com if you believe your account has been accessed without your permission or you notice suspicious activity. Follow the Terms of Service (/legal/terms); do not attempt to probe, scan, or breach the platform's security except through the Vulnerability Disclosure Policy (/legal/vulnerability-disclosure).

15. Policy Updates

Purpose. To explain changes to this Policy. We may update this Policy as our controls and providers evolve. Where required by law, we give notice of material changes. The current version and its effective date are shown on this page. This Policy does not reduce your statutory rights, and it is read together with the Terms of Service (/legal/terms) and Privacy Policy (/legal/privacy).

16. Contact

Purpose. To tell you how to reach us on security matters.

Contracting entity: WiseWave Limited (Company Number 762171)
Registered office: 39 Cooley Park, Dundalk, Co. Louth, A91 AP2V, Ireland
Email: info@tirvea.com

To report a security vulnerability, please use the Vulnerability Disclosure Policy (/legal/vulnerability-disclosure). For privacy questions, see the Privacy Policy (/legal/privacy); for the overall contract, the Terms of Service (/legal/terms).