Incident Response Policy

9.1 Definition of a Security Incident

Any event that threatens the confidentiality, integrity, or availability of Hirfa's data or systems, including but not limited to: unauthorized account access, data breach or leakage, abuse of the OTP/notification system, credible threats directed at Hirfa Personnel or Users, denial-of-service activity, or any attempted or successful system compromise.

9.2 Incident Response Lifecycle

• Phase 1 — Detection & Reporting: Any team member, User, or automated monitoring system that identifies a potential incident reports it immediately to security@gethirfa.com or the internal emergency escalation channel.
• Phase 2 — Triage & Severity Classification: The incident is classified within one hour of report as Critical / High / Medium / Low, based on scope of data affected, number of Users impacted, and exploitability.
• Phase 3 — Containment: Immediate action is taken to stop the incident from spreading or worsening — e.g., suspending a compromised account, revoking a leaked API key, isolating an affected system component.
• Phase 4 — Investigation: Root-cause analysis and full scope assessment (which data, which Users, what timeframe were affected). The Evidence Preservation Procedure (Section 10) is triggered immediately at this phase to lock down all relevant logs and artifacts before they can be altered or lost.
• Phase 5 — Remediation: The underlying vulnerability or process failure that enabled the incident is permanently fixed, and affected credentials/tokens are rotated.
• Phase 6 — Notification: Where the incident involves personal data, affected Users and, where legally required, the competent Egyptian data-protection authority are notified within the timeframe mandated by the PDPL, describing the nature of the breach, the data involved, and the mitigation steps taken.
• Phase 7 — Post-Incident Review: A full written post-mortem is produced, capturing root cause, timeline, response effectiveness, and concrete policy/technical improvements, which are then implemented and tracked to completion.

9.3 Incident Response Team

A cross-functional team is activated for any Critical or High severity incident: the lead technical owner (CTO), the designated security owner, and an executive representative (CEO), with additional Personnel pulled in as the incident requires.

9.4 Handling Direct Threats

Where an incident involves a direct threat — including threats of violence or intimidation communicated to Hirfa staff or Users, or abuse of the OTP system to harass a phone number — Hirfa will: (a) immediately preserve all related evidence per Section 10; (b) suspend the offending account pending investigation; (c) escalate to Egyptian law enforcement authorities where the conduct may constitute a criminal offense; and (d) support the affected party throughout the process.

9.5 Communication During an Incident

During an active Critical incident, Hirfa maintains a single point of coordinated communication to avoid conflicting public statements, and provides Users with clear, factual, and timely updates without unnecessary technical jargon.