Incident Response Policy

Purpose and scope

This policy describes how Nexma identifies, contains, investigates, and discloses security incidents affecting the Nexma platform, customer data, or Nexma personnel and systems.

It applies to all production environments and to any system that stores or processes customer data. It is binding on Nexma employees, contractors, and on-call responders.

Definitions

Security event

An observable occurrence in a system that has potential security relevance — for example, a failed login spike or an unexpected configuration change. Events are not yet confirmed incidents.

Security incident

A confirmed event that violates the confidentiality, integrity, or availability of Nexma systems or customer data, or that places them at credible risk.

Personal data breach

An incident leading to the accidental or unlawful destruction, loss, alteration, unauthorized disclosure of, or access to personal data processed by Nexma.

Vulnerability

A weakness in a system that could be exploited. Vulnerabilities are managed through patching and remediation; if active exploitation is suspected, they become incidents.

Roles and responsibilities

Roles in an incident are assigned at declaration time. A single person may hold multiple roles in smaller incidents.

• On-call responder — First responder for production alerts and reported issues. Performs initial triage, classifies severity, and pages the Security Lead for confirmed incidents.
• Security Lead (Incident Commander) — Owns the incident from declaration to closure. Coordinates response, decides on containment actions, owns customer and regulatory notification timing.
• Engineering Lead — Allocates engineering resources, owns technical investigation and remediation, ensures fixes ship through normal change-management once it is safe to do so.
• Executive sponsor — For Sev1 and Sev2 incidents, an executive is briefed and consulted on material decisions, including external communication and disclosure.
• Legal counsel — Consulted on incidents involving personal data, regulatory exposure, or contractual notification obligations.

Detection sources

Incidents may be detected through several channels. All of them feed the same intake process:

• Automated monitoring — Application metrics, error rates, authentication logs, and platform anomaly alerts.
• Customer reports — Reports received via support channels, the security@nexma.ai mailbox, or account managers.
• Subprocessor notifications — Security advisories or breach notifications from infrastructure providers and other subprocessors.
• External researchers — Reports received via responsible disclosure or security@nexma.ai from independent researchers.
• Internal discovery — Findings raised by Nexma engineers in the course of normal work, code review, or routine audits.

Severity classification

Each declared incident is assigned a severity at declaration. Severity may be revised as more is known.

Response procedures

Incidents follow a phased response. Each phase is logged so the post-incident review can reconstruct what happened.

1. Triage — Confirm the event is an incident, assign a severity, page the right people, and open the incident channel and timeline.
2. Containment — Limit blast radius. This may include revoking credentials, isolating systems, rolling back changes, or rate-limiting suspect activity.
3. Eradication — Remove the underlying cause — patching the vulnerability, rotating exposed secrets, or removing malicious artifacts.
4. Recovery — Restore affected services to normal operation. Verify integrity before declaring closure and continue heightened monitoring for a defined period.
5. Review — Conduct a written post-incident review within 14 days. Identify follow-up actions and assign owners.

Customer and regulatory notification

For confirmed personal data breaches affecting customer data, Nexma will notify the affected customer without undue delay and, where feasible, within 72 hours of confirmation. The notification will describe the nature of the breach, the categories of data affected, the likely consequences, and the measures Nexma has taken or proposes to take.

Where Nexma acts as a processor under applicable data protection law, the customer (controller) is responsible for downstream notification to regulators and data subjects. Nexma will provide the information the controller reasonably needs to meet that obligation.

For non-breach incidents that materially affect service availability or trust, Nexma will publish an incident summary on its status page and, where appropriate, write a public post-incident report.

Post-incident review

Every Sev1 and Sev2 incident generates a written post-incident review within 14 days of closure. The review is blameless: it focuses on systems, controls, and decisions, not on individuals.

Reviews include a timeline, the root cause, what worked, what did not, and a list of concrete follow-up actions with owners and target dates. Action items are tracked to completion.

Communication templates

Nexma maintains internal templates for incident communications — customer notifications, status page updates, regulator notifications, and public post-incident reports — so responders can communicate quickly and consistently under pressure.

Templates are reviewed annually and after any incident that exposes a communication gap.

Tabletop exercises

Nexma runs at least one tabletop exercise per year. Exercises walk responders through a realistic scenario — a confirmed data exposure, a critical vendor breach, or a credential compromise — to test the response process end-to-end.

Findings from each exercise feed back into this policy, into the communication templates, and into engineering follow-up where the platform itself needs to change.

Contact

To report a suspected security incident or vulnerability affecting Nexma, contact the security team. Encrypted reporting is available on request.

Email: legal@nexma.ai