Incident Response Plan

Document Control

Revision history

1. Purpose

This plan sets out the operational procedure Hamurlabs follows when an information security incident is suspected or detected. It implements the Incident Management Policy (HL-ISMS-POL-05) and is designed for a fast, small-team response appropriate to the size and structure of Hamurlabs, while meeting the legal and contractual notification obligations that apply to a SaaS provider processing customer data.

2. Incident Response Organisation

1. On-call: an on-call schedule is defined so that an Information Security Manager (ISM) — or a designated deputy from the engineering leadership — is reachable at all times. Up-to-date contact information for the on-call ISM is maintained in the company directory/ITSM tool.
2. Notification channel: potential incidents are reported to [email protected] and, for urgent matters, through the designated on-call alerting channel. Automated monitoring alerts route to the same channel.
3. Management sponsors: the co-founders act as sponsors for engineering, legal/commercial, people and external-communication decisions; external legal counsel is engaged for breach notification matters as needed.
4. Distribution and training: this plan is distributed to all staff, kept accessible in the company documentation space, and all staff complete training on it at least once per year.

3. What to Report

The following situations must be reported as potential incidents:

• Ineffective or bypassed security controls;
• Suspected breach of confidentiality, integrity or availability of information — including customer data in HaROS;
• Human errors with security impact (e.g. data sent to the wrong recipient, exposed credentials);
• Non-compliance with policies or guidelines;
• Breaches of physical security;
• Uncontrolled system changes;
• Malfunctions of software or hardware indicative of compromise;
• Access violations, lost/stolen devices, phishing and social-engineering attempts;
• Anomalous system behaviour indicative of an attack or an actual breach.

4. Response Procedure

Step 1 — Report (within 24 hours of awareness)

Any user who identifies or suspects an incident notifies [email protected] or the on-call ISM immediately, and in any case within 24 hours, including: description of the incident; date, time and location; who discovered it and how; known evidence; and affected system(s). Where a manager is notified first, the manager immediately escalates to the on-call ISM.

Step 2 — Triage and severity (within 24 hours of the report)

The ISM conducts a preliminary investigation and risk assessment to confirm the details. If confirmed, the ISM assigns a severity level that determines the response effort:

Step 3 — Containment and investigation

The ISM, in consultation with management sponsors, determines and executes containment and resolution activities (e.g. isolating workloads, revoking credentials and sessions, blocking traffic, disabling accounts). The ISM preserves forensic evidence (logs, files, images, screenshots) before destructive actions wherever possible; evidence is retained for potential provision to law enforcement if the incident is determined to be malicious.

Step 4 — Breach notification assessment (High/Medium; runs in parallel)

For any incident that may involve personal data, the ISM immediately assesses, with legal counsel where needed, whether the incident is a personal data breach and which notification duties in Section 5 of the Incident Management Policy apply. The 72-hour clocks for GDPR and KVKK, and any shorter contractual deadlines in customer DPAs, run from awareness — the assessment must not wait for full investigation to complete. Notifications are made in phases where information is incomplete.

Step 5 — Communications (High/Medium)

The ISM works with Executive Management (and external counsel/PR support where engaged) to create and execute a communications plan for affected customers, personnel, and — where required — supervisory authorities and data subjects. Customer communications for HaROS incidents are coordinated with the relevant account owner and follow the single-point-of-contact rules in the applicable customer contract. No external statement is made without Executive Management approval.

Step 6 — Resolution and recovery

The ISM takes all necessary steps to resolve the incident and recover systems, data and connectivity. All technical steps are documented in the incident log, which must contain: description; severity level; root cause; evidence; mitigations applied (e.g. patch, re-image, key rotation); status (open, closed, archived); and disclosures (parties to which details were disclosed — customers, vendors, authorities, law enforcement).

Step 7 — Post-mortem

After resolution, the ISM conducts a post-mortem including root cause analysis and lessons learned, notifies users as appropriate, arranges additional training if needed, and tracks corrective actions to completion. Where a user’s activity is deemed malicious, People/HR takes disciplinary action; the CEO may elect to involve external authorities (law enforcement, private forensic firms, government organisations) depending on severity.

5. Contact Reference

This contact table must be reviewed quarterly by the ISM and immediately upon personnel changes.

6. Testing

This plan is tested at least annually (tabletop exercise or simulated incident, including a personal-data-breach scenario with notification-deadline tracking). Findings are documented and incorporated into the next revision.