Trust and security

1. The product and the data we process

erekini.eu is multi-tenant SaaS for small Latvian businesses. It issues invoices, keeps product and stock records, prepares and sends payment reminders following the flow the user has set (the user approves the pre-court warning before it is sent), digitises receipts and supplier invoices, and prepares accounting documents. Laima is a feature of this service: the system's assistant, which carries out the automated processing described below. It is not a separate product or a separate controller.

We process account data (email, name, password hashed with bcrypt), company data (invoices, clients, expenses, contracts), personal data about the user's clients (name, email, telephone, registration number, address), AI-generated drafts of reminders and documents, and payment metadata (Stripe customer and subscription IDs; we never store card data ourselves, and the PCI scope is managed by Stripe).

2. Architecture and hosting

• Application: a Node.js/Express API and a statically exported Next.js dashboard, deployed on Vercel (serverless infrastructure, application servers in Frankfurt).
• Database, authentication and files: Supabase (managed PostgreSQL) with Row Level Security, in the EU region in Stockholm (eu-north-1).
• Artificial intelligence: the Anthropic Claude API, with the model claude-sonnet-5-5. Anthropic does not use this content to train models.
• Transactional email: Zoho SMTP, EU data centre.
• Payments: Stripe.

Data is always encrypted in transit (TLS/HTTPS), which both Vercel and Supabase provide.

Where the data is: the database, authentication and files are in Sweden, the application servers in Germany, and email is sent from Zoho's EU data centre. Through the Anthropic Claude API and Stripe, data is processed on those companies' global infrastructure, with transfers under standard contractual clauses; see section 5 of the Privacy Policy.

3. Tenant isolation

One account can never read, list or act on another account's data. This is enforced in code, not left to an AI model:

• The authenticated organisation ID is derived from the server session and validated against the user's actual memberships. A cookie stored in the user's browser can only choose between organisations the user already belongs to; it cannot point at any other account.
• The browser does not read or write user data in the database directly. All user data goes through our server, which limits every request to the user's organisation. The database roles available from the browser have no write access to any table and can read only public reference tables. Supabase Row Level Security (RLS) acts as an additional layer of protection.
• Every week, an automated check in an attacker's role, both signed out and as a signed-in user with no data, tests the production database: what can be read, which functions can be called and where data can be written. Any finding fails the check and raises an alert.

4. AI safety and human oversight

• Human oversight, enforced in code. Payment reminders are sent following the flow and tone the user has set in advance; the strictest, pre-court warning is never sent without the user's approval. No decision with legal effects is taken solely on the basis of automated processing.
• AI-generated drafts (reminders, documents, analyses) are decision support; the user makes the final decision.
• No AI-generated database queries. Every query is written in our code and always limited to the user's organisation; the model can only put a search term or a filter into one, and that is neutralised first.

5. Other technical measures

• Passwords are stored hashed (bcrypt) by Supabase Auth, and the email address must be confirmed. The session is a signed cookie that browser scripts cannot read; signing out, changing the password and resetting it revoke it. Two-factor authentication is available.
• Role-based access control for organisation members.
• Rate limiting on sensitive endpoints.
• Incoming Stripe webhooks are verified with Stripe's signature, while scheduled tasks (cron) accept their secret key only in a header, never in the URL.
• No secrets (API keys, signing keys, encryption keys) are stored in the repository; they come from environment variables and the Vercel secret store.
• Automatic backups are provided by Supabase as a managed service.

6. Sub-processors and their certifications

We use several infrastructure service providers. The certifications below belong to the providers themselves, not to erekini.eu: they attest to the security of the data centres and platforms we run on, under the shared-responsibility model.

The full list of processing activities and sub-processors (data categories, purposes, legal basis) is in our Privacy Policy, and the terms of processing are in the Data Processing Agreement, which is available to every user.

7. Our own certification status

To be plain about it: erekini.eu is not currently independently certified to ISO/IEC 27001 or SOC 2. Such certificates can only be issued by an accredited external auditor after an audit period, and the fact that our infrastructure providers (Supabase, Vercel, Stripe, Zoho, Cloudflare) are certified does not mean that erekini.eu itself is.

Our internal security measures are designed in line with the SOC 2 Trust Services Criteria and the principles of ISO/IEC 27001:2022 Annex A, and we keep an internal control map that links each control to a specific place in the code or configuration. Customers and partners who need a security questionnaire or a summary of controls can write to info@erekini.eu, and we will send it.

8. CSA STAR registry

Our free CSA STAR Level 1 self-assessment (Cloud Security Alliance Consensus Assessments Initiative Questionnaire, CAIQ v4.0.3) is published in the CSA STAR registry. It documents our security controls against the Cloud Controls Matrix (CCM). The public entry and the full CAIQ self-assessment can be viewed and downloaded here: cloudsecurityalliance.org/star/registry/erekini-eu.

CSA STAR Level 1Self-Assessment, CAIQ v4.0.3

9. Reporting a security issue

If you find a possible vulnerability, please do not disclose it publicly. Write to us privately at info@erekini.eu, with the steps to reproduce it, its impact and, if you can, a suggested fix. We allow a reasonable time to fix the issue before any public disclosure.

To be confirmedContact details for CERT.LV (Latvia's national computer security incident response team) will be added here if and when this applies to a specific incident.