Skip to main content

Incident Response Policy

Effective date: January 1, 2026
Applies to: sayhii production systems and the Services

1. Purpose​

sayhii is committed to protecting the confidentiality, integrity, and availability of its systems and customer data. This customer-facing document summarizes how sayhii identifies, responds to, mitigates, and communicates about security incidents that may impact the Services.

This document is a high-level overview; it does not describe internal procedures in full detail.

2. Scope​

This document applies to incidents that may affect:

  • sayhii production environments and infrastructure
  • Customer data processed to deliver the Services
  • Internal systems used to operate the Services
  • Third-party services used to provide or support the Services

3. What We Consider a Security Incident​

A security incident is any actual or suspected event that compromises, or could reasonably compromise, the confidentiality, integrity, or availability of sayhii systems or customer data.

Examples include:

  • Unauthorized access to systems or data
  • Confirmed or suspected exposure of customer data
  • Compromised credentials, API keys, or secrets
  • Malware or suspicious activity affecting systems
  • Misconfigurations resulting in unintended access
  • Denial-of-service or service disruption

When uncertainty exists, sayhii treats the event as a potential incident and evaluates it accordingly.

4. Incident Response Responsibilities​

sayhii maintains incident response ownership and accountability. During an incident, responsibilities typically include:

  • Incident lead: Coordinates response, decisions, and documentation
  • Technical responders: Investigate, contain, remediate, and recover systems
  • Communications: Coordinate internal and external communications, including customer notifications

5. Incident Handling Lifecycle​

sayhii follows a structured incident response approach:

5.1 Identification​

Incidents may be identified through monitoring, automated alerts, customer reports, vendor notifications, or internal discovery. sayhii records key information such as time of discovery, affected components (if known), and the initial assessment.

5.2 Containment​

We take actions to limit impact and prevent further access, which may include credential rotation, account restrictions, configuration changes, and preserving relevant logs or evidence.

Containment actions take priority over full root-cause analysis.

5.3 Investigation​

We investigate to determine what occurred, how it occurred, and what systems or data may have been affected.

5.4 Eradication and Remediation​

We address root causes, apply fixes, and implement preventive measures intended to reduce the likelihood of recurrence.

5.5 Recovery​

We restore services to normal operation (if impacted) and validate secure operation before resuming standard operations.

5.6 Lessons Learned​

We conduct post-incident review activities to document findings and improve controls, policies, and procedures.

6. Communication and Customer Notification​

6.1 Internal Communication​

Incident communications are coordinated, time-stamped, and based on verified information. We aim to avoid speculation and prioritize accuracy.

6.2 Customer Communication​

sayhii notifies customers when:

  • Customer data is confirmed to be exposed, or
  • Service availability is materially impacted

Customer communications may include, as appropriate:

  • A high-level description of what happened
  • The type of data impacted (if any) based on verified information
  • Actions taken by sayhii
  • Recommended customer actions, if applicable

Notifications and communications are provided consistent with contractual and legal requirements.

7. Breach Notification​

If an incident is determined to constitute a data breach involving personal data, sayhii will:

  • Assess the scope and nature of the breach
  • Determine notification obligations based on contractual, legal, and regulatory requirements
  • Notify affected customers consistent with those obligations
  • Coordinate regulator or authority notifications when required

Breach notifications are limited to verified facts available at the time of notification.

8. Third-Party Incidents​

If an incident originates from a third-party service provider:

  • sayhii assesses the potential impact to the Services and customer data
  • We monitor and document vendor communications
  • Customers are notified if their data or access is affected, consistent with contractual and legal requirements

9. Documentation and Retention​

sayhii maintains incident documentation appropriate to the severity and nature of the incident, which may include a summary, response timeline, investigation details, remediation actions, and preventive improvements.

Incident records are retained in accordance with internal retention practices and applicable contractual and legal requirements.

10. Review and Testing​

This customer-facing description summarizes relevant internal policies and practices. sayhii’s internal incident response policies and procedures are reviewed periodically, and this description is updated as necessary to reflect material changes. sayhii may test incident response readiness through internal exercises or simulations.

For related practices, see the customer-facing overviews in Data Privacy, Retention, and Destruction and Secure SDLC.