Data Protection Policy
Document Control
| Document ID | HL-ISMS-POL-09 |
|---|---|
| Document Title | Data Protection Policy |
| Classification | Internal |
| Version | 2.0 |
| Status | Approved |
| Document Owner | Information Security Manager (ISM) |
| Approved by | Executive Management |
| Effective Date | 30.10.2026 |
| Next Review Date | Annually from effective date, or upon significant change |
| Applies to | Hamurlabs Elektronik Hizmetler Yazılım ve Ticaret A.Ş. (Istanbul, Türkiye) and Hamurlabs BV (Leuven, Belgium), together "Hamurlabs" |
1. Purpose and Scope
Hamurlabs takes the confidentiality and integrity of customer data very seriously and ensures data is protected from unauthorised access and available when needed. This policy outlines the procedures and technical controls supporting data protection. It applies to all production systems that create, receive, store or transmit Hamurlabs customer data ("Production Systems"). The ISM facilitates and maintains this policy and ensures all personnel have reviewed it.
2. General Requirements
- Data must be handled and protected according to its classification (HL-ISMS-POL-04) and approved encryption standards (HL-ISMS-POL-07).
- Data of the same classification is stored in a given repository wherever possible; security controls are applied according to the highest classification of data in the repository.
- Personnel do not have standing administrative access to production data during normal operations; access follows the approval process below. Exceptions are limited to emergency operations such as forensic analysis and manual disaster recovery, and are logged.
- Production Systems disable services not required for their business purpose.
- All access to Production Systems is logged.
- Production Systems have security monitoring enabled, including activity monitoring, vulnerability scanning and, where applicable, file integrity monitoring and malware detection.
3. Hosting and Customer Data Protection
Hamurlabs hosts the HaROS production environment on Google Cloud in the europe-west1 region (St. Ghislain, Belgium). Backups and any replication for redundancy and disaster recovery are maintained within European Union regions. Data residency commitments given to specific customers in their contracts prevail and are implemented per contract.
All Hamurlabs personnel adhere to the following to reduce the risk of compromising production data:
- Implement and review controls designed to protect production data from improper alteration or destruction;
- Ensure confidential data is stored in a manner supporting access logs and automated monitoring for potential security incidents;
- Ensure customer production data is segmented and accessible only to the customer authorised to access it;
- Encrypt all production data at rest on encrypted volumes, with keys managed through Google Cloud KMS in accordance with the Encryption Policy; key material is accessible only to designated privileged identities.
Access
Employee access to production is guarded by an approval process and is disabled by default. When approved, temporary access is granted for the defined need. Production access grants are reviewed by the ISM on a case-by-case basis and quarterly in aggregate, per the User Access Control Policy.
Separation
Customer data is logically separated at the database/datastore level using a unique customer identifier. Separation is enforced at the API layer: the client authenticates against an account, the customer identifier is embedded in the access token, and every database/datastore query is scoped by that identifier.
Monitoring
Hamurlabs uses Google Cloud’s operations and logging suite together with centralised log aggregation and alerting tooling to monitor the cloud service operation. On system failure or alarm, key personnel are notified by chat, e-mail and/or phone to take corrective action.
Confidentiality / Non-Disclosure Agreements
Hamurlabs uses confidentiality or non-disclosure agreements with legally enforceable terms for internal and external parties. NDAs address: definition of protected information; duration; required actions upon termination; responsibilities to avoid unauthorised disclosure; ownership of information, trade secrets and IP; permitted use; audit and monitoring of activities involving confidential information; notification of unauthorised disclosure; return or destruction terms; actions upon breach; and periodic review.
4. Data at Rest
All databases, data stores and file systems are encrypted per the Encryption Policy. Stored data is categorised and subject to the retention schedule in the Data Destruction and Retention Policy (HL-ISMS-POL-10), considering statutory, regulatory and contractual requirements, the type of data, and the storage medium. Storage and disposal follow the Asset Management Policy and the Data Destruction and Retention Policy, including authorisation to access stored data, identification of records and retention periods, retrievability across technology change, and appropriate disposal methods.
5. Data in Transit
- Data is transferred only where necessary for effective business processes; the sensitivity, volume and impact of loss are considered before choosing the transfer method.
- All external data transmission is encrypted end-to-end using strong protocols, key exchange and ciphers (TLS 1.2+), including transfers to cloud infrastructure and third-party vendors and applications.
- Confidential data must not be sent over end-user messaging channels (e-mail, chat) unless encryption in transit is enforced and the channel is approved; messages are checked for correct addressing before sending; use of external public services (instant messaging, social networks, file sharing) for company data requires prior approval.
6. Event Logging
All systems handling confidential information, accepting network connections, or making authentication/authorisation decisions record audit logs sufficient to answer: what activity was performed, by whom, where, when, how, and with what outcome.
- Logged activities include: create/read/update/delete of confidential information; network connections initiated and accepted; authentication and authorisation events (login/logout); granting, modification or revocation of access rights and privilege changes; system, network and service configuration changes including patches; application start/stop/restart; and abnormal terminations or resource-exhaustion events.
- Each log entry identifies at least: type of action; subsystem performing it; identifiers of the requesting subject (user, host, IP); before/after values for data updates where feasible; date-time with timezone (UTC preferred); whether the action was allowed or denied; and denial reason codes where applicable.
- Log integrity: logs are stored to support integrity and enterprise-level analysis; clocks are synchronised via NTP across all servers.
- Privileged-user safeguards: administrators are not permitted to erase or de-activate logs of their own activities; logs are copied in real time to systems outside administrator control; and logs are reviewed regularly to maintain accountability of privileged users.