Security

Yonevo is a platform for residential complex and apartment building managements that stores their financial data and resident information in one place. Below, we explain the security mechanisms in place. For enterprise documentation and service-level assessments, see the Enterprise Verification section at the end of this page.

• Each property's data is isolated at the data layer; this boundary is not left to the care of application code.
• Record changes are written to the audit trail at the data layer.
• Authorisation is role-based and built on the principle of least privilege.
• All traffic is encrypted with TLS; HSTS is enforced.

This page is a technical statement, not marketing copy. No standard or certification that we cannot verify is claimed here.

In a multi-tenant system, the most serious risk is one property's data becoming visible to another. Yonevo does not leave this to the developer's care:

• The property boundary is enforced in the data access layer. A query without a property context does not run — it behaves fail-closed by design: when in doubt, it closes rather than opens.
• The same rule applies to deletions and updates; it is not possible to change a record that is out of scope.
• For users who manage several properties, the active property context is kept per browser tab so with two different properties open in two tabs, records never get mixed up.

• The application servers are in Turkey. The database and the application layer are hosted in Turkey.
• Web traffic passes through a CDN and firewall (Cloudflare) layer, which provides DDoS protection and filtering of malicious requests.
• All traffic is carried over TLS. HSTS (including subdomains), Content-Security-Policy, X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy and Cross-Origin-Opener-Policy headers are active.
• The application runs under a process manager; its health endpoints (application, database and tenant context) can be queried continuously.

• In transit: All client–server traffic is encrypted with TLS; HTTP requests are redirected to HTTPS.
• For sensitive fields: Critical fields such as bank integration credentials are not stored as plain text in the database; they are encrypted with AES-256-GCM into a single bundle, which is versioned to allow key rotation in future.
• Passwords: No password is stored in a reversible form; each one is hashed using bcrypt before storage.
• Sessions and verification codes: Refresh tokens are tracked with a unique identifier and rotated when used.

• Two-step verification: Verification based on TOTP (RFC 6238), which works with authenticator apps, and on SMS is supported. Choosing to remember a device does not switch off two-step verification.
• Session security: Authentication is handled through an HttpOnly cookie and the token is never exposed to browser scripts. CSRF protection is active. Short-lived access tokens and rotating refresh tokens are used.
• Role-based permissions: Users can only perform the actions they are authorised for, on the properties they are authorised for.
• Brute-force protection: Rate limiting is applied to sign-in and verification endpoints; SMS verification is limited by both IP address and phone number.
• Password policy: Password complexity is enforced by a single central rule; reset links are single-use and time-limited.

• Database access uses parameterised queries through an ORM and never SQL built by string concatenation.
• Input validation is schema-based; unexpected fields are rejected.
• File uploads undergo type and size validation and uploaded files are stored in a separate directory outside the application root.
• A strict Content-Security-Policy limits where scripts can be loaded from.
• Application errors are collected in a central error log console and deduplicated by fingerprint.

• Bank integrations are read-only. Only account transactions are read; Yonevo cannot transfer money from your account — no such capability exists anywhere in the code.
• Bank credentials (user, company/branch code, keys) are not stored as plain text in the database; they are kept as a single bundle encrypted with AES-256-GCM and are never sent to the client under any circumstances.
• Connections are made through the bank's authorised services and no screen-scraping bot is used. The sign-in screen is not imitated and passwords are not stored.
• The provider registry is fail-closed by design: a bank code that is not defined can be neither saved nor queried.
• Each bank is defined in its own module and shared services, background jobs and the interface have no knowledge of bank names. When a bank's service changes, only that module is affected — other bank connections, collections, accounting and reporting keep working.
• Banks with direct statement integration at present: Türkiye İş Bankası and Garanti BBVA. For other banks, the statement file is imported.

• Card payments are processed by iyzico, a PCI-DSS certified payment institution as the payment institution.
• Card details are neither stored nor logged on Yonevo's servers. Card data is entered on the payment institution's own page.
• Payment transactions, their results and returned error codes are recorded in an auditable way.

Backups are run at two levels: platform database backups and per-property backup plans.

• The platform uses encrypted database backups and PostgreSQL write-ahead log (WAL) archiving. Full and differential backups provide the infrastructure for returning to a point in time within the archive (PITR).
• Operational tools support checking a backup by restoring it in a separate environment. The recovery scope depends on the available backups and transaction logs; it does not imply a specific recovery time or a zero data loss commitment.
• Per-property backups are taken on a daily, weekly or monthly schedule set for each property by the Yonevo team.
• Backup jobs are run by an hourly task and by default operate during low-traffic hours.
• Backups are stored with a content list (manifest) and a SHA-256 checksum, so it can be seen which backup was taken when and what it covers.

Per-property backup plans are managed by the Yonevo team from the management console; there is no backup setting in the customer panel. These plans are separate from the platform's database backup and archiving processes.

• On the servers, host-based security monitoring agents run, and their events are sent to a central monitoring server hosted in Turkey to be collected. Agent status and connections are followed from the operations panel; alerts support investigation and response processes.
• Record changes are written to the audit trail at the data layer so creation, update and deletion events are tracked in that layer.
• For deletions, the full image of the record before deletion is captured in the audit trail.
• Who changed which record, and when, can be viewed on the Audit Logs screen in the management panel.
• Log retention periods are configurable; statutory retention periods apply to financial records (see Privacy Policy).

Your customer data (maintenance fee, resident and accounting records) is stored on servers in Turkey — however, some of the infrastructure services we use to run the service are based abroad, and in this context limited technical data may be transferred abroad. In the interest of transparency, we list all of them:

• CDN and firewall: Web traffic passes through Cloudflare; IP addresses and request metadata are processed in this context.
• Visit and sign-up source measurement: Visit analytics and Google Analytics on the marketing pages depend on analytics consent. Consented source and campaign information is linked to the Yonevo account at sign-up. Advertising click identifiers additionally depend on marketing consent. Names, email addresses, phone numbers, account content and full URL queries are not added to measurement events. You can change your cookie preferences at any time.
• Mobile notifications: App notifications are delivered through the Expo notification service; device notification tokens and notification content are processed in this context.
• SMS and email: Service providers are used for delivery; the number or address a message is sent to, and its content, are processed by these providers.

The legal basis and scope of these transfers are explained in detail in the KVKK Privacy Notice.

If we detect that personal data has been obtained unlawfully, then under KVKK Art. 12/5 we notify the Personal Data Protection Board as soon as possible, and in any case within 72 hours — and we also notify the data subjects concerned.

• The scope of the incident is determined and the affected systems are isolated.
• Affected customers are told what happened and what they need to do.
• The root cause analysis and the permanent measures taken are shared.

• KVKK — for our obligations under Law No. 6698, see the Privacy Notice.
• VUK / TTK — statutory periods for keeping financial records are applied.
• PCI-DSS — card payments are made through a PCI-DSS certified payment institution; Yonevo does not store card data.

A certification process such as ISO 27001 or SOC 2 for Yonevo itself has not yet been completed and we do not claim to hold any such certification.

In an enterprise assessment, technical controls, independent documents and contractually defined service levels are reviewed separately.

• The current scope of independent penetration testing and third-party audit documents should be confirmed with the sales team.
• Using a security tool does not mean holding an ISO 27001 or SOC 2 certification.
• Central security monitoring is not the same as 24/7 human on-call cover or a commitment to a specific response time.
• Having PITR infrastructure does not mean that specific RPO/RTO values are guaranteed in every situation.
• Enterprise identity provider integration (SSO / SAML) is not offered as part of the standard product.

If one of these points is decisive for you during an enterprise assessment, you can write to satis@yonevo.com to discuss the current documents and service scope.

If you have found a security vulnerability, please contact us before sharing it publicly:

• Email: guvenlik@yonevo.com
• We confirm receipt of your report as soon as possible.
• Depending on the severity of the finding, we share a remediation plan and keep you informed throughout the process.

During testing, please do not access real customer data, do not disrupt the service and work only with a test account that belongs to you.

Security reports can be sent to guvenlik@yonevo.com, and general questions to destek@yonevo.com as appropriate. During enterprise assessments we share detailed information about the architecture and data flows — satis@yonevo.com.