Mailbuttons operates an Agent Mail API entrusted with customer email and credentials, so a clear, practised response to security incidents is essential. This policy sets out how we detect, report, contain and recover from incidents, and how we meet our legal notification obligations.

# Purpose and scope

This policy defines how Code Cutter Limited (trading as Mailbuttons) responds to information security events, incidents and personal data breaches across all production systems, supporting services and endpoints. It applies to everyone working on Mailbuttons and aligns with ISO/IEC 27001:2022 Annex A controls 5.24–5.27 (incident management planning, assessment, response and learning) and 6.8 (event reporting).

A security event is any observed occurrence that may have security relevance. A security incident is an event, or series of events, that compromises the confidentiality, integrity or availability of systems or data, or breaches this policy. A personal data breach is an incident leading to the accidental or unlawful destruction, loss, alteration, unauthorised disclosure of, or access to personal data.

# Policy

Reporting. Anyone — staff, customers, researchers or the public — may report a suspected incident to security@mailbuttons.com. We acknowledge reports within two UK business days. This channel is shared with our vulnerability disclosure process; a confirmed exploitable vulnerability is triaged as an incident.

Triage and severity. The ISMS Owner triages each report and classifies severity:

• Critical — confirmed breach of customer data, loss of the master encryption key, or total service outage.
• High — credible compromise of a production system or credential, or partial outage affecting many customers.
• Medium — contained issue with limited or no data impact.
• Low — minor or near-miss events with no material impact.

Severity drives response speed, escalation and communication.

Response lifecycle. We follow a structured lifecycle:

1. Identification — confirm the incident, record a timeline, and assign the ISMS Owner as incident lead.
2. Containment — isolate affected systems, revoke or rotate compromised credentials and API keys, and limit further harm.
3. Eradication — remove the root cause, patch vulnerabilities and verify no persistence remains.
4. Recovery — restore service from known-good state (see the Business Continuity and Disaster Recovery Policy), monitor for recurrence, and confirm normal operation.

Evidence preservation. We preserve logs, system images and relevant records before remediation where feasible, maintaining a chain of custody sufficient to support analysis and any regulatory or legal process.

Breach notification. Where an incident is a personal data breach likely to result in a risk to individuals, we notify the Information Commissioner's Office (ICO) without undue delay and within 72 hours of becoming aware. Where the risk to individuals is high, and for affected customers under our contractual commitments, we notify affected data subjects and customers promptly with the nature of the breach, likely consequences and mitigating actions. Notifications that prove unnecessary are documented with reasons.

Communications. The ISMS Owner owns all incident communications. We aim to be factual, timely and proportionate, and we avoid speculation before facts are established.

Post-incident review. After every High or Critical incident — and other incidents where useful — we conduct a review capturing root cause, what worked, what did not, and corrective actions with owners and dates. Lessons feed back into controls and this policy. Where appropriate, and once affected parties are protected, we publish a post-incident analysis on our Trust Center in the interest of transparency.

# Responsibilities

The ISMS Owner is accountable for incident management, acts as incident lead, makes notification decisions and approves external communications. Everyone working on Mailbuttons must report suspected incidents promptly and assist with response. Suppliers are expected to notify us of incidents affecting our data without undue delay.

# Review

This policy is reviewed at least annually and after any material change, and is approved by the ISMS Owner.

Related: Business Continuity and Disaster Recovery Policy, Supplier Security Policy, Physical and Environmental Security Policy