Security and Data Protection Overview

ESearchCy — Cyprus Company Records Service

DRAFT TEMPLATE — NOT LEGAL ADVICE. Review by qualified legal counsel required before launch. Only publish statements that are actually true of your implementation — remove or amend anything not yet in place; overstating security measures creates legal risk.

Effective date: 27 August 2026 · Last updated: 27 August 2026 · Version: 1.0

This page summarises the technical measures actually in place today to protect the Platform and your data. We have deliberately kept it to what is implemented rather than to what sounds reassuring: ESearchCy is a small operation, and this page should let you judge it accurately. It is informational; detailed contractual commitments (for business customers) are available on request at info@esearchcy.com.

1. Infrastructure

• The Platform runs on Google Firebase / Google Cloud Platform. Our application code runs as Cloud Functions in the EU region europe-west1 (Belgium); stored data sits in [[TO CONFIRM: Firestore and Cloud Storage location, e.g. eur3 / europe-west1]].
• Google maintains certifications including ISO 27001 and SOC 2 for that underlying infrastructure. Those certifications cover Google's platform, not ESearchCy — we are not ourselves certified to any security standard.
• We do not operate our own servers, and we do not run a separate staging copy of production data.

2. Encryption and credentials

• All traffic is served over HTTPS; connections are encrypted in transit with TLS.
• Data at rest is encrypted by the hosting platform, as standard for Google Cloud storage.
• Passwords. Where you sign in with an email address and password, we store only a salted scrypt hash of your password (random per-account salt, 64-byte derived key) in our own database, and we compare it in constant time. We never store, log, or are able to read your plaintext password. We do not use Firebase Authentication's password provider for this.
• Google sign-in. Where you sign in with Google, we verify a Firebase Authentication ID token issued by Google and store no password for your account at all.
• Sessions. A successful sign-in issues a random 256-bit session token, stored server-side and valid for up to 30 days or until you sign out. Password-reset, email-verification and account-deletion links are single-use, time-limited, and stored only as SHA-256 hashes.
• Registry credentials. Government (gov.cy CyLogin) credentials — both the operator-held logins we use to search on your behalf and, where you have chosen to supply your own, yours — are encrypted at rest with AES-256-GCM before being written to the database, under a key held as a Cloud Functions secret and not stored in the database itself. The same encryption protects stored registry session cookies and the operator's own payment card used for automated registry payments. We do not store customers' payment cards: credit purchases go to Stripe, and the Registrar's €10 is entered on the Registrar's own JCC page.

3. Access control

• Access to production data is limited to the operator of the service.
• The administrative interface is protected by a single long, shared bearer token held as a platform secret and checked in constant time on every request. It is not multi-factor authentication and there are no per-administrator accounts. We are stating this plainly rather than implying stronger controls than we have.
• Authentication endpoints (sign-up, sign-in, password reset, Google sign-in, credential saving) are rate-limited per IP address to slow brute-force and enumeration attempts.
• Application and administrative activity is recorded in the hosting platform's logs.

4. Application security

• Authentication and session management are handled by our own server-side session tokens, as described in section 2.
• Payment card data for credit purchases is handled exclusively by Stripe, a PCI DSS–compliant processor; those card details never touch our servers.
• The €10 Registrar fee is paid on the Registrar's own JCC payment page.
• Server-side input validation is applied to submitted data, and dependencies are updated as part of ordinary maintenance. We do not currently run automated penetration testing or hold an external security audit.

5. Resilience and backups

• The hosting platform provides the redundancy and durability of Google Cloud's managed services.
• We do not currently operate a scheduled backup or point-in-time-recovery configuration of our own, and we therefore make no commitment about restoring data from a particular point in time. [[TO CONFIRM: whether a Firestore backup / PITR schedule is to be enabled before launch — if so, replace this bullet with the real schedule and retention period]]
• Delivered files and download links are time-limited; see the Data Retention and Deletion Notice. Keep your own copy of any file you need to retain.

6. Personnel and organisation

• The service is operated by a small team; everyone with data access is bound by confidentiality obligations.
• Vendors processing personal data are engaged under Art. 28 GDPR data processing agreements (see the Third-Party Services Notice).

7. Incident response and breach notification

We maintain an incident response process. In the event of a personal data breach likely to result in a risk to individuals, we will notify the competent supervisory authority within 72 hours where required by Art. 33 GDPR, and affected users without undue delay where required by Art. 34 GDPR.

8. Reporting vulnerabilities

If you believe you have found a security vulnerability, please report it responsibly to info@esearchcy.com. Do not access other users' data or disrupt the Service. We will acknowledge reports promptly and keep you informed of remediation.

9. Your part

Use a strong, unique password, keep credentials confidential, and contact us immediately at info@esearchcy.com if you suspect unauthorised access to your account.

Contact: info@esearchcy.com