This policy sets out how Mailbuttons knows what it has, who owns it, and how it is handled and retired. It supports the Information Security Policy.

# Purpose and scope

You cannot protect what you have not catalogued. The purpose of this policy is to maintain a current inventory of our information assets and systems and to ensure each is owned, handled according to its classification, and disposed of securely. It applies to all Mailbuttons assets, whether self-operated or held in supplier accounts (Annex A 5.9, 5.10, 5.11).

# Policy

# Inventory

We maintain an inventory of information assets and the systems that hold them. As a small team this is a single maintained register rather than a heavyweight CMDB, but it is kept current. It covers at least:

• Data stores — PostgreSQL databases and RustFS (S3-compatible) object storage.
• Compute — VPS hosts (Fasthosts), and the Stalwart email cluster we self-operate.
• Source and configuration — source code repositories and infrastructure configuration.
• SaaS and supplier accounts — Cloudflare, Stripe, Backblaze, Anthropic, our hosting and identity (Kanidm) accounts; the canonical sub-processor list lives on the Trust Center at /trust#sub-processors.
• Domains and DNS — registered domains and DNS configuration.
• Keys and secrets — including the critical master key (LLM_KEY_ENCRYPTION_KEY), which is backed up off-box.

Each entry records what the asset is, its owner, and its data classification.

# Ownership

Every asset has an owner accountable for its protection. In our founder-led team the ISMS Owner owns assets by default; where a contractor is engaged, specific assets may be assigned to them for the duration of their work.

# Acceptable handling

Assets are handled according to the classification assigned under our Data Classification and Retention Policy. That policy defines the encryption, access and sharing rules per tier; this policy requires that those rules are applied to every inventoried asset. Customer Data and secrets receive the strictest handling, including encryption at rest (AES-256-GCM for secrets) and in transit (TLS 1.2+/1.3).

# Access — least privilege

Access to assets is granted on a least-privilege, need-to-know basis (Annex A 5.15, 5.18). We default to the minimum access required for a task, prefer single-sign-on via Kanidm OIDC where supported, and protect supplier accounts with strong authentication. Because we are a micro-team we accept that the ISMS Owner holds broad access; we compensate with auditability — administrative actions are logged, and a customer-facing immutable audit log records sensitive operations.

# Offboarding

When a contractor's engagement ends, we remove all access promptly — accounts disabled, credentials and tokens revoked, shared secrets rotated, and any assets returned or wiped (Annex A 5.11, 6.5). Offboarding is treated as a discrete checklist, not an afterthought.

# Disposal and decommissioning

When an asset, host or storage medium is retired, we ensure data is rendered unrecoverable before disposal — secure deletion, cryptographic erasure, or destruction as appropriate (Annex A 7.10, 7.14). Decommissioned VPS hosts and storage are wiped, supplier accounts are closed, and associated keys and credentials are rotated or destroyed. Secure deletion of customer data on expiry or request is governed by the Data Classification and Retention Policy.

# Responsibilities

The ISMS Owner maintains the asset inventory, assigns ownership, grants and revokes access, and oversees secure disposal. Anyone with access to a Mailbuttons asset must handle it according to its classification and report any loss or exposure to [email protected].

# Review

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

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