This policy sets out how Mailbuttons manages information-security risk in a way that a small, founder-led team can run consistently. It supports the Information Security Policy.

# Purpose and scope

The purpose is to ensure that risks to the confidentiality, integrity and availability of customer email and platform data are identified, understood, and treated to a level the business can accept. It applies to all Mailbuttons systems, data, people and suppliers (Annex A 5.7, 6.1).

# Policy

# Identifying risk

We identify information-security risks using both an asset-based and a threat-based view. We start from the asset inventory maintained under our Asset Management Policy — databases, object storage, VPS hosts, source repositories, supplier accounts and domains — and ask what could compromise each one. We also consider threats directly: account compromise, supplier failure, data exposure, key loss, and loss of availability. New risks are raised whenever we change architecture, add a supplier, or learn from an incident.

A worked example of an asset-based risk we actively manage: our host provider, Fasthosts, offers no provider-level snapshots, so server-level disaster recovery is not available to us. We treat this as a recorded risk and mitigate it with filesystem-level, client-side-encrypted off-site backups (Backblaze, EU/Amsterdam).

# Assessing risk

Each risk is recorded in a risk register with an owner, a description, and a score derived from likelihood × impact, each rated on a simple scale (for example 1–5). The product gives an overall rating that lets us rank risks and decide which need treatment first. Because we are a micro-team, the register is deliberately lightweight but kept current — a usable register beats an elaborate one that is never updated.

# Treating risk

For each risk above our tolerance we choose a treatment option:

• Mitigate — apply or strengthen a control (encryption, least-privilege access, monitoring, backups).
• Accept — formally accept a residual risk where the cost of further treatment is disproportionate.
• Transfer — share the risk, for example via a supplier under contract, or insurance.
• Avoid — stop or change the activity that creates the risk.

Selected controls are recorded against the ISO/IEC 27001:2022 Annex A control set in our Statement of Applicability (SoA), which states which controls apply, why, and their implementation status. The risk register and the SoA are kept consistent with each other.

# Accepting risk

The ISMS Owner (the founder) owns risk acceptance. No residual risk is accepted without being recorded, with a rationale and, where appropriate, a review date. This is the one decision we never make implicitly.

# Cadence

We review the risk register and SoA at least annually, and additionally on any material change — new supplier, significant architecture change, or new regulatory requirement — and after any significant security incident, so that lessons feed back into our risk picture (Annex A 5.27).

# Responsibilities

The ISMS Owner maintains the risk register and SoA, assigns risk owners, decides treatments and accepts residual risk. Anyone working on Mailbuttons must raise newly identified risks to security@mailbuttons.com.

# Review

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

Related: Information Security Policy, Asset Management Policy, Data Classification and Retention Policy.