Good logs are how a small team sees what its systems are doing and reconstructs what happened after the fact. This policy sets out what Code Cutter Limited (trading as Mailbuttons) records, how those records are protected, and how they are monitored and used.

# Purpose and scope

This policy governs event logging, log protection, monitoring, alerting and log review across Mailbuttons production systems and the customer-facing audit log. It supports ISO/IEC 27001:2022 Annex A 8.15 (logging), 8.16 (monitoring activities) and 8.17 (clock synchronisation).

# Policy

What we log. We record security-relevant events including: authentication and authorisation events (via Kanidm OIDC); administrative and production actions such as deployments, migrations and configuration changes; and agent execution runs. In addition, Mailbuttons maintains a customer-facing audit log that records significant actions taken on a customer's tenant, giving customers visibility into what happened in their own account.

Immutability and retention. The customer-facing audit log is append-only and immutable — entries cannot be altered or deleted after the fact. Audit logs are retained for 7 years on Business and Enterprise plans, supporting customer compliance needs and our own ISO 27001 and UK/EU GDPR obligations. Internal application logs are retained for an operationally appropriate period.

Minimising sensitive data. Logs are designed not to store secrets, credentials or authentication tokens, and to minimise personal data in line with UK/EU GDPR and the DPA 2018. We log enough to investigate and account for actions, and no more. Secrets at rest elsewhere remain AES-256-GCM encrypted; they are not written to logs.

Protection and access. Logs are protected against tampering and unauthorised access. Access to internal logs is restricted to the ISMS Owner on a least-privilege basis. The immutability of the audit log protects its integrity as evidence.

Monitoring and alerting. We monitor for anomalies and errors — failed authentication patterns, application errors, sandbox or SSRF-guard violations, and abnormal agent behaviour — and alert on conditions that warrant attention. As a micro-team we rely on automated alerting to surface issues rather than continuous human watch; we are explicit that we do not operate a 24/7 SOC.

Time synchronisation. System clocks are synchronised to a reliable time source so that timestamps across logs are consistent and events can be correlated reliably during investigation (Annex A 8.17).

Periodic review. Logs and alerts are reviewed periodically by the ISMS Owner, not only reactively, so that slow-burning issues and misconfigurations are caught. Review findings may feed into vulnerability management and secure development practice.

Use in incident response. Logs are a primary source of evidence during incident response. They are used to detect incidents, establish scope and timeline, support containment and remediation decisions, and meet any regulatory notification obligations. The append-only audit log provides a trustworthy record for these purposes.

# Responsibilities

The ISMS Owner is accountable for this policy: for ensuring appropriate events are logged, that logs are protected, retained and minimised, that monitoring and alerting are in place and clocks synchronised, and that logs are reviewed periodically and used effectively in incidents.

# Review

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

Related: Secure Development Policy, Change Management Policy, Vulnerability and Patch Management Policy, Incident Response Policy