​

1. Purpose, scope and principles

This policy describes the technical and organisational measures Raviosoft OÜ applies to protect the personal data of TamNerede users. It is a public summary of our data security obligations under GDPR Art. 32 and KVKK Art. 12; detailed internal procedures are not published for security reasons.

Scope. The TamNerede mobile apps, website, server infrastructure, admin panels, our employees and contractors, and all service providers with access to data.

​

Core principles

• Privacy by design and by default: new features are designed to collect as little data as possible; privacy-protective settings are on by default.

• Data minimisation: we keep only the data needed, for only as long as needed. Wherever possible, data is processed on the device (for example crash detection sensor data).

• Least privilege: staff access only the data needed for their role, and only for as long as needed.

• Defence in depth: we apply layered security so that the failure of a single control does not expose data.

• Risk-based approach: we apply extra measures to high-risk data such as location, children's and health data; a data protection impact assessment (DPIA) has been carried out for this processing and is updated [annually].

• ​

Reference standards. Our security programme is built on ISO/IEC 27001 and OWASP MASVS (Mobile Application Security Verification Standard). [If you hold a certification or independent audit report, state it here; otherwise keep the wording “built on”.]

​

2. Governance and responsibilities

The management board of Raviosoft OÜ has ultimate responsibility for data security. Day-to-day responsibilities are assigned as follows:

​

• Security lead: Running the security programme, incident response, planning tests: 

• ​Data Protection Officer (DPO): Legal compliance, DPIAs, user requests, liaison with authorities

• Engineering team: Secure coding, patch management, infrastructure configuration

​

Personnel security

• All employees and contractors with access to data sign a confidentiality undertaking.

• They receive data protection and security training at onboarding and at least once a year.

• When the relationship ends, all access rights are revoked the same day and company devices are returned.

• Policy violations are subject to disciplinary procedures.

Review. This policy and the related internal procedures are reviewed at least annually and after any significant change or incident.

3. Technical security measures

Encryption

• In transit: all traffic between the app and our servers is encrypted with TLS 1.2 or higher; the mobile app uses certificate pinning.

• At rest: databases, file stores and backups are encrypted with AES-256. Sensitive fields such as location history, chat messages and the health card are additionally encrypted at application level.

• Key management: encryption keys are stored in the cloud provider's hardware-backed key management service [KMS/HSM], rotated regularly and kept separately from the data.

• On the device: the app protects session tokens and cached sensitive data with the iOS Keychain and Android Keystore.
   

Infrastructure security

• Servers are hosted in data centres of an ISO 27001 and SOC 2 certified cloud provider [in the EU region].

• Production is separated from development and test environments at network and account level. Real user data is not used in test environments.

• Databases are not directly reachable from the internet; they are accessible only over private networks.

• A web application firewall (WAF), DDoS protection and rate limiting are in place.

• Operating system and dependency patches are applied within [7] days for critical vulnerabilities and within [30] days for others.
   

Access control

• Access to production systems is limited by role-based authorisation, and multi-factor authentication (MFA) is mandatory.

• Access to user data is off by default; temporary, approved and logged access is granted for support or incident investigation.

• Permissions are reviewed [quarterly].

• All administrative actions are logged immutably, and alerts are raised for anomalous access.
   

Protecting user accounts

• Passwords are stored as hashes using a strong, salted algorithm (Argon2 or bcrypt).

• Users are offered two-step verification; logins from a new device trigger a notification.

• Rate limiting and account lockout protect against brute-force attacks.

• Users can see their active sessions and end them remotely.
   

4. Additional measures for location, children's and chat data

Location data can reveal a person's home, school, workplace and daily routine. We therefore apply the following additional controls to our most sensitive data.
 

Location data

• Location history is stored in databases separate from directly identifying account data, using pseudonymised identifiers.

• Only the user's Circle members can access location data; sharing permissions are re-verified server-side on every request.

• Location records past their retention period are deleted daily by automated jobs.

• Precise location data is not passed to analytics or advertising systems; this separation is technically enforced.

• Staff can access an individual's location history only at the user's request, for an abuse investigation or under a legal obligation, with two-person approval and logging.
   

Safeguards against misuse (non-consensual tracking)

• Adults can join a Circle only by consenting from their own device.

• When location sharing is on, this is always visible in the app; the app icon cannot be hidden.

• Users get a “Who can see me?” screen listing everyone who sees their location and can leave a Circle with one tap.

• Users receive periodic reminders of who they are sharing their location with.
   

Children's data

• Advertising, analytics and marketing SDKs are disabled at code level in Child Accounts.

• Creating a Child Account and changing the parent require additional verification.

• Children's chats are limited to Circle members approved by the parent; no messages can be received from outside.
   

Chat and health data

• Chat messages and media files are stored encrypted; media is accessed only through short-lived signed links. [If end-to-end encryption is used, state it explicitly here.]

• Health information on the emergency card is encrypted with a separate key and shown only to the selected emergency contacts during an SOS.
   

5. Application and software development security

• Secure development lifecycle: new features undergo threat modelling and privacy review at the design stage.

• Code review: every change going to production is reviewed by at least one other developer.

• Automated scanning: source code (SAST), dependencies (SCA) and leaked secrets are scanned automatically on every build.

• Dependency management: third-party libraries and SDKs are assessed for security and privacy before being added, and the data they collect is documented.

• Penetration testing: independent penetration tests of the mobile apps and APIs are carried out [at least annually] and after major changes.

• Mobile app hardening: code obfuscation, root/jailbreak detection, secure storage and debug output disabled in production builds.

• API security: authentication and object-level authorisation on every request (so no user can query another user's location), input validation and rate limiting.

• Log hygiene: application and server logs do not contain location coordinates, message content, passwords or tokens.
   

6. Supplier and sub-processor management

Every service provider with access to personal data is assessed before contracting and at regular intervals.

1. Due diligence: security certifications (for example ISO 27001, SOC 2), data location, sub-processors and breach history are reviewed.

2. Contract: a data processing agreement under GDPR Art. 28 is signed, together with the EU Standard Contractual Clauses and the KVKK standard contract where required.

3. Data minimisation: only the data the supplier needs to provide its service is shared.

4. Monitoring: critical suppliers are reassessed annually and must notify us of security incidents without delay.

5. Termination: at the end of the contract, return or deletion of data and confirmation thereof is required.

The current list of sub-processors is published at [tamnerede.app/subprocessors]. We notify business customers at least [30] days before adding a new sub-processor.
 

7. Data breach management and notification

From the moment we become aware of a personal data breach, we follow our written incident response plan. The plan is tested in a drill [annually].
 

Response steps

1. Detection and logging: the incident is detected through automated alerts or reports from staff, users or researchers and recorded in the breach register.

2. Containment: affected systems are isolated and compromised credentials and keys are revoked.

3. Assessment: the types of data affected, the number of people and the level of risk to them are determined. Breaches involving location, children's or health data are treated as high risk.

4. Notification: the time limits below are followed.

5. Remediation and improvement: the root cause is fixed, lessons are learned and controls are updated.
    

Notification time limits

​

• Andmekaitse Inspektsioon (Estonia): Within 72 hours of becoming aware (not required if the breach is unlikely to result in a risk to individuals)

• Personal Data Protection Board (Türkiye): For breaches affecting users in Türkiye, within 72 hours of becoming aware

• Affected users: Without undue delay where there is a high risk, by in-app notice and email explaining what happened, likely consequences and steps to take

• Business customers (as controllers): Without undue delay and within [48] hours at the latest

• Other authorities and users: According to the time limits of US states, the United Kingdom (ICO, 72 hours) and other countries
   

Local law

All breaches are recorded with the facts, effects and remedial action taken, even when no notification is required.
 

8. Backup, business continuity and data disposal

Backup. Databases are backed up [daily], encrypted, to a geographically separate region within the EU. Backups are kept for up to [35] days and restores are tested [quarterly].

Business continuity. Critical services (location sharing, notifications, SOS) run redundantly across multiple availability zones. Our targets:

• Recovery time objective (RTO): [4] hours

• Recovery point objective (RPO): [1] hour

• Service outages are announced at [status.tamnerede.com].
   

Data disposal. Data past its retention period or subject to a deletion request is:

• Deleted from live systems by automated jobs or irreversibly anonymised.

• Removed from backups at the end of the backup cycle (within [35] days at the latest).

• Physical storage media are destroyed through the cloud provider's certified disposal processes (NIST SP 800-88).
   

For users in Türkiye, deletion, destruction and anonymisation are logged in line with the Regulation on the Deletion, Destruction or Anonymisation of Personal Data, and the logs are kept for at least 3 years.
 

9. The user's role and vulnerability reporting

Security is a shared responsibility. To protect your account and your family, we recommend that you:

• Choose a strong password you do not use anywhere else and turn on two-step verification.

• Protect your device with a screen lock and keep the operating system and TamNerede up to date.

• Check the “Who can see me?” screen regularly; remove any member or device you do not recognise immediately.

• Remember that TamNerede will never ask for your password or verification code by email, SMS or phone.

• If someone is tracking you without your consent, use the in-app safety checklist, leave the Circle and, if needed, contact local support lines or law enforcement.
   

Vulnerability reporting (responsible disclosure)

If you have found a security vulnerability in TamNerede, please report it to [security@tamnerede.app]. [security.txt: tamnerede.app/.well-known/security.txt]

• We acknowledge your report within [3] business days and keep you informed during the investigation.

• We will not take legal action against research done in good faith and in line with these rules.

• Use only your own accounts and test data; do not access, modify or delete other users' data.

• Disruptive testing (DoS), social engineering and physical attacks are out of scope.

• Do not disclose details publicly until the issue is fixed; we will agree the disclosure timing with you.
   

Contact. Security: [support@raviosoft.com] · Data Protection Officer: [dpo@raviosoft.com] · Raviosoft OÜ, Tallinn, Estonia