Incident Management Policy
Document Control
| Document ID | HL-ISMS-POL-05 |
|---|---|
| Document Title | Incident Management 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" |
Revision history
| Version | Date | Author | Description of Change |
|---|---|---|---|
| 1.0 | — | — | Initial template-based version (superseded) |
| 2.0 | 30.10.2026 | ISM | Full rewrite: adapted to Hamurlabs group structure (A.Ş. + BV), Google Cloud environment, KVKK/GDPR legal basis, ISO/IEC 27001 alignment; roles and contact points corrected |
1. Purpose
This policy establishes controls to ensure the detection of security vulnerabilities and incidents at Hamurlabs, and a quick, consistent and lawful response to security breaches. It defines what must be reported, by whom, within what timeframes, and the responsibilities and legal notification obligations that apply. The operational, step-by-step procedure is set out in the Incident Response Plan (HL-ISMS-PLN-01), which implements this policy.
2. Scope
This policy applies to all users of Hamurlabs information systems: employees and contractors of both Hamurlabs entities, and external parties that come into contact with systems and information controlled by Hamurlabs (together, "users"). It covers incidents affecting the HaROS platform and customer data, corporate systems, endpoints, offices and third-party services used by Hamurlabs. This policy must be made readily available to all users.
3. Background and Definitions
A key objective of the Hamurlabs Information Security Programme is to detect weaknesses and vulnerabilities so that incidents and breaches are prevented wherever possible. Despite preventive controls, incidents can occur; when they do, Hamurlabs is committed to rapidly identifying, containing, investigating, resolving and communicating them — including meeting the notification obligations Hamurlabs has under data protection law and under its customer contracts as a processor/sub-processor.
| Information Security Vulnerability | A weakness in an information system, security procedure or administrative control that could be exploited to gain unauthorised access to information or to disrupt processing. |
|---|---|
| Information Security Incident | A suspected, attempted, successful or imminent threat of unauthorised access, use, disclosure, modification or destruction of information; interference with IT operations; or a significant violation of information security policy. |
| Personal Data Breach | A breach of security leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to, personal data (GDPR Art. 4(12); KVKK terminology: "veri ihlali"). Every personal data breach is an incident; not every incident is a personal data breach. |
4. Policy
- All users must report any vulnerability, incident, or event pointing to a possible incident as quickly as possible and in any case within 24 hours of becoming aware of it.
- Incidents must be reported to [email protected] or directly to the Information Security Manager (ISM). This is the single incident reporting channel for the Hamurlabs group; reports concerning either entity are handled through the same process.
- Users must be trained on incident reporting procedures and their responsibilities. Failure to report an information security incident is itself a security violation and may result in disciplinary action.
- Information and artifacts associated with incidents (files, logs, screen captures) must be preserved as potential evidence.
- All incidents must be handled through the Incident Response Plan, including severity assessment, containment, resolution, documentation in the incident log, and post-mortem.
- Hamurlabs must employ automated scanning, logging and alerting mechanisms to identify possible vulnerabilities and incidents. Identified vulnerabilities must be remediated within defined timeframes based on severity; identified incidents must be investigated within defined timeframes based on severity.
5. Legal and Contractual Notification Obligations
Where an incident is, or may be, a personal data breach, the following obligations apply in addition to internal handling, and the assessment must begin immediately upon confirmation of the incident:
| Hamurlabs role | Obligation | Deadline | Owner |
|---|---|---|---|
| Controller under GDPR (e.g. breach of Hamurlabs BV employee or business-contact data) | Notify the competent supervisory authority (for Hamurlabs BV: the Belgian Data Protection Authority) unless the breach is unlikely to result in a risk to individuals; notify affected data subjects where the breach is likely to result in a high risk | 72 hours from awareness (authority); without undue delay (data subjects) | ISM + General Management, with legal counsel |
| Processor / sub-processor under GDPR (breach affecting EU customer data in HaROS) | Notify the affected customer(s) (controller or processor above Hamurlabs in the chain) with the information required under GDPR Art. 33(3) and the relevant DPA | Without undue delay after becoming aware; any shorter contractual deadline in the customer DPA prevails | ISM + account owner |
| Controller under KVKK (Hamurlabs A.Ş. data) | Notify the Turkish Personal Data Protection Board (KVK Kurulu) via the prescribed breach notification form, and notify affected data subjects as soon as possible | 72 hours from awareness (Board) | ISM + General Management, with legal counsel |
| Processor under KVKK (breach affecting Turkish customer data in HaROS) | Notify the affected customer(s) without delay so that they can meet their own KVKK obligations; deadlines in the customer contract/DPA prevail | Without delay; contractual deadline if shorter | ISM + account owner |
Notification decisions, their justification (including a decision not to notify), and all communications must be documented in the incident record. Where deadlines cannot be met, the reasons for delay must be documented and notifications made in phases as information becomes available.
6. Roles and Responsibilities
| ISM | Facilitates and maintains this policy; leads incident response; assigns severity; coordinates investigation, containment, resolution, notification and post-mortem; maintains the incident log; ensures all personnel have reviewed this policy. |
|---|---|
| Executive Management | Acts as management sponsor; approves external notifications and communications; decides on involvement of external authorities, forensic firms or legal counsel. |
| Engineering / on-call personnel | Detect, escalate and support technical containment and recovery. |
| People/HR | Supports communications to personnel and any disciplinary process where user activity is deemed malicious or negligent. |
| All users | Report incidents within 24 hours; preserve evidence; cooperate with the response. |
7. Periodic Evaluation
Incident response processes are reviewed periodically for effectiveness. Personnel expected to respond to incidents receive appropriate training, and the general population is trained on their reporting responsibilities at least annually. The Incident Response Plan is tested at least annually through a tabletop exercise or simulation; test results and lessons learned are documented and fed back into the plan.