Security and TOMs Overview

Effective date: Aug 10, 2026

This document summarizes the technical and organizational measures used by Lingonberry Island Ltd. to protect personal data in Buyervalues.ai. It supports, but does not replace, Annex 2 of the Data Processing Agreement. Measures are applied according to risk, the relevant Service feature, and the production configuration.

1. Current production architecture

The public frontend is delivered through Firebase Hosting.
The API, background workers, and PostgreSQL database run in containers on a Finland-hosted Tietokettu VPS.
Nginx terminates external TLS and proxies requests to the backend.
PostgreSQL is on the private container network and has no public database port in the production Compose configuration.
OpenAI, Firebase Authentication, Google Workspace, and any enabled optional services process only the data needed for their stated functions.

The current and feature-dependent providers are identified in the Subprocessor List.

2. Identity, authorization, and tenant isolation

Firebase Authentication and verified identity tokens are used for User authentication.
Role-based authorization and Workspace identifiers restrict tenant data access.
Administrative routes have additional superadmin checks; Workspace ID 1 is reserved for system operations.
Internal public-baseline reuse paths remove Customer-specific provenance and manual modifications before cross-Workspace reuse.
Production access is limited to authorized personnel according to role and operational need.

3. Network, application, and secrets controls

TLS protects external traffic in transit.
Reverse-proxy, host-firewall, request-size, and rate-limit controls reduce network and application abuse.
URL retrieval includes SSRF defenses and validation; API inputs are validated.
Billing webhooks are signature-verified when Stripe billing is enabled.
Production secrets and service-account material are kept outside source control with restricted host access.

4. Logging, monitoring, and change management

Security-relevant audit events and operational logs support troubleshooting, abuse investigation, and incident response.
Prometheus-compatible metrics and monitoring hooks may be enabled for reliability and capacity monitoring.
Error-monitoring integrations such as Sentry are not treated as active subprocessors unless enabled after review and notice.
Production changes follow documented deployment, migration, health-check, and rollback procedures.

5. Availability, recovery, and deletion

Database and service health checks, container restart policies, and documented recovery procedures support availability.
Workspace, intake, job, and URL-batch lifecycle controls support deletion and minimization.
Deleted Customer Personal Data may remain in access-restricted backups until the configured backup expires or is overwritten; deletion rules are reapplied after a restoration.
Backup schedules, restoration tests, and retention settings are tracked in the internal retention registry and must be verified for each production release.

6. Encryption at rest

The production architecture uses access controls and tenant isolation to protect stored data. Host-volume and backup encryption depend on the selected hosting and backup configuration. Company does not represent those controls as enabled until they have been verified and recorded for the production environment.

7. Personnel and incident response

Personnel with access to personal data are subject to confidentiality and least-privilege requirements.
Security events are assessed, contained, documented, and remediated under the incident process.
Where Company is a processor, it notifies the affected Customer of a confirmed personal-data breach without undue delay after becoming aware of it, as described in the DPA.
Security measures are reviewed after material architecture, provider, or risk changes.

No security measure eliminates all risk. Customers remain responsible for User access, lawful input data, endpoint security, and their own controller duties.