Audit-log Retention & Protection Policy

Owner: Security Officer · Approved by leadership · Version 1.0 · Effective 27 May 2026 · Next review 27 May 2027

1. Purpose

This policy defines how Glassbreak categorises, retains, protects, and disposes of audit data — and what audit data customers can export from the platform. It is the controlled document referenced by Annex A.5.33 (protection of records), A.8.15 (logging), A.8.16 (monitoring activities), and the equivalent SOC 2 Common Criteria (CC2.1, CC7.2) and NIST SP 800-53 (AU family).

2. Scope

This policy applies to all audit data generated by or about the Glassbreak hosted platform and its supporting infrastructure, including:

Application-level audit log entries about state-changing actions taken within the product;
Request and trace logs emitted by the application during handling of user and system traffic;
Security telemetry (rate-limit events, MFA outcomes, failed-auth patterns, refresh-token reuse detections, daily security-posture probe results);
Admin-action audit log entries recording privileged operator activity;
Infrastructure and sub-processor activity logs accessible to Glassbreak (cloud-provider audit logs, IaC apply logs, CI activity);
Records required by other policies that have an audit quality (incident register, access register, credential-rotation log, workforce-acknowledgement records).

It does not apply to customer-side audit data that customers generate within their own organisations on the platform; that data is governed by the customer's own retention schedule, with the platform offering the export and access described in section 7 below.

3. Categories of audit data

3.1 Application audit log

Definition. Structured entries recording every state-changing action within the product: account and organisation lifecycle, membership and role changes, secret create / share / revoke, message lifecycle, audit log read access, billing-state changes.
Source. Application code, written synchronously on the same transaction as the underlying state change.
Storage. Per-vertical Postgres audit table (Neon for the AWS vertical, Scaleway Managed DB for the Scaleway vertical).
Retention. At least 12 months online; longer for entries related to a customer who has requested extended audit-log retention as an enterprise option.
Integrity protection. Append-only schema enforced at the application layer; per-organisation row isolation; modification of audit entries is a Gross-category sanctions violation. Tamper-evident chain (cryptographic chaining of entries) is on the Q4 2026 plan (RTP R-05).
Disposal. Entries older than the retention period are aged out per the scheduled cron; tenant deletion under /legal/data-request removes the related audit entries in line with the declared deletion timeline.
Customer export. Available via the in-product /secure/audit route for the organisations the requesting member belongs to.

3.2 Request and trace logs

Definition. Per-request log lines and OpenTelemetry traces for application handling — method, path, status, latency, trace id, span id, span kind, selected attributes. Excludes request body and response body for routes that handle Class CT or Class K material; excludes secrets even where the body is logged.
Source. Application middleware and OTLP instrumentation.
Storage. Grafana Cloud (Tempo for traces, Loki for logs, Mimir for metrics).
Retention. 14–30 days online at the Grafana Cloud tier in use; long-term archival is by aggregation, not by raw retention.
Integrity protection. Sub-processor integrity guarantees (Grafana Cloud retention is immutable within the retention window); access is restricted to authorised workforce members; observability access is logged.
Disposal. Aged out per the Grafana Cloud retention; structured aggregations preserved as long as they remain useful for trend and capacity analysis.
Customer export. Not directly available to customers; relevant excerpts may be provided as part of an incident-investigation cooperation under the DPA.

3.3 Security telemetry

Definition. Rate-limit decisions, MFA successes and failures, refresh-token rotations and reuse-family detections, password-reset attempts, abuse reports, daily security-posture probe results.
Source. Application middleware, MFA service, refresh-token service, daily snapshot runner.
Storage. Per-vertical Postgres for application-internal records; Grafana Cloud for metrics-form telemetry; the daily snapshot is mirrored to the public-trust publication when measured green for 30+ consecutive days.
Retention. At least 12 months for in-database security telemetry; per Grafana Cloud retention for the metrics representation.
Integrity protection.Append-only semantics in the database; sub-processor immutability for the Grafana Cloud portion; public trust publication is automated and outside any single workforce member's ability to suppress.
Disposal. In-database entries aged out per the scheduled cron; entries linked to an open incident are preserved until the incident is closed.
Customer export.Aggregate security metrics about the customer's own organisation are available via the in-product organisation security dashboard.

3.4 Admin-action audit log

Definition. Records of privileged workforce actions taken against the platform — operator console actions in the AWS and Scaleway planes, OpenTofu apply events, admin-impersonation events, credential-rotation events, support-tool access events.
Source. Application admin-action service (for in-product admin actions); cloud-provider audit services and CI logs (for infrastructure-level events); credential-rotation log (for secret-store events).
Storage. Per-vertical Postgres admin-action table; cloud-provider audit services (CloudWatch logs for AWS; Scaleway audit logs for Scaleway); CI logs for pipeline events.
Retention. At least 12 monthsonline per the Information Security Policy§3.4. Sub-processor logs follow the sub-processor's own retention (CloudWatch with a minimum 90-day tier; Scaleway audit log with provider default; CI activity for at least 12 months); copies of security-relevant events from these sources are consolidated into the Glassbreak admin-action audit log on ingestion.
Integrity protection. Append-only schema; access is restricted; admin-action audit log is in scope of the tamper-evident chain on the Q4 2026 plan (RTP R-05). Modification of admin-action entries is a Gross-category sanctions violation.
Disposal. Entries older than the retention period are aged out per the scheduled cron; entries linked to an open incident or to a regulatory request are preserved.
Customer export. Not directly available to customers (these are records of Glassbreak workforce activity, not customer activity); a customer-facing summary of any admin-impersonation event affecting their organisation is delivered to the organisation owner per the impersonation procedure.

3.5 Cross-vertical sync log

Definition. Records of state-changing sync messages exchanged between the AWS and Scaleway verticals over the HMAC-signed transport.
Source. The sync transport on each vertical.
Storage. Per-vertical Postgres sync audit table.
Retention. At least 90 days online; longer for entries linked to an open reconciliation or investigation.
Integrity protection. HMAC signature on every message protects integrity in transit; entries on both sides allow detection of asymmetric partitions and tampering (DR scenarios 14, 15, 17).
Disposal. Aged out per the scheduled cron after the retention period.
Customer export. Not directly available; aggregate consistency metrics surfaced via the public trust page.

3.6 Records of policy origin (cross-reference)

The following records have audit quality but are governed by their source policies; this policy cross-references their retention schedules:

Incident register — at least 5 years per/policies/incident-response §11; personal-data-breach records never less than 5 years or the statutory minimum.
Access register — active grant + 12 months after revocation per /policies/onboarding §10.
Credential-rotation log — at least 5 years per /policies/offboarding §12.
Workforce acknowledgement records — at least 5 years post-termination per /policies/onboarding §10.
Training completion records — at least 5 years per /policies/onboarding §10.
Right-to-work and background-check records — per employment-law minima and at least 3 years post-termination per /policies/onboarding §§3.1, 10.

4. Integrity protection — current and target

4.1 Current state

Append-only schemas at the application layer for the audit-quality tables.
Per-organisation isolation at the query client layer prevents cross-tenant disclosure of audit entries.
Replication of structured telemetry to Grafana Cloud provides an off-application-plane copy that limits the impact of in-place tampering.
Modification or deletion of audit entries (other than aged-out disposal per this policy) is a Gross-category sanctions violation.
Daily security-posture probes verify a subset of audit-related invariants and surface failures publicly when sustained.

4.2 Target state

Cryptographic chaining of admin-action audit entries (each entry binds the prior entry hash) so that any insertion, deletion, or modification is detectable on verification.
Periodic publication of the chain head hash to a transparency surface so that internal manipulation is detectable externally.
Independent third-party verification of chain integrity on the certification path.

The target state is tracked as RTP R-05 with a Q4 2026 target.

5. Access

Read access to audit data is granted on a least-privilege basis through the access register.
Workforce read access to audit data containing customer metadata is itself logged in the admin-action audit log; a customer-facing record of any in-product audit read by Glassbreak workforce is available on request to the organisation owner.
Bulk export of audit data is restricted; only the Security Officer (or a delegate) may authorise.
Sub-processor audit data access (CloudWatch, Scaleway audit log) is governed by the same access register.

6. Disposal

Automated aging-out runs per scheduled cron; failures open a deduplicated GitHub issue under the standard smoke-test path.
Tenant deletion under /legal/data-request removes the related audit entries on the declared deletion timeline; cryptographic erasure is used where applicable.
Audit entries linked to an open incident or to a regulatory or legal request are preserved beyond the standard retention until the matter is closed.
Disposal events themselves are audit-logged as part of the admin-action audit log.

7. Customer export

In-product export. Members may export the audit log of organisations they belong to via the in-product /secure/audit route, scoped to their authorisation level.
API export. Authorised members may export audit data programmatically through the documented API endpoints.
Extended retention. Enterprise customers may request extended retention beyond the standard 12 months; documented as a contractual term with associated charge.
Data-subject rights. Subject access, rectification, and erasure requests under GDPR / UK GDPR / FADP are handled per /legal/data-request with the standard 30-day response window.
Incident cooperation. During an incident affecting a customer, audit excerpts relevant to the incident are provided per the DPA cooperation obligations.

8. Roles

Security Officer. Owns this policy and the retention cadences; authorises any deviation; reviews the access register quarterly.
Engineering. Implements and operates the retention crons; implements the tamper-evident target state; surfaces failures via observability.
Workforce members with audit access. Comply with the access rules; report any anomaly in audit data integrity to security@glassbreak.io.

9. Compliance and enforcement

Compliance with this policy is mandatory.
Modification of audit entries outside the disposal cron is a Gross-category violation per /policies/sanctions §3.3; reported under the Incident Response Policy as a SEV-1.

10. Exceptions

Exceptions require written approval by the Security Officer with a recorded expiry and compensating controls. Examples that may justify an exception: extended retention to support a regulatory request; reduced retention for a sub-processor that does not offer the standard tier (with compensating aggregation).

11. Review

This policy is reviewed at least annually and after any material change to the application audit surface, the sub-processor mix that holds audit data, or the regulatory environment. The next scheduled review is 27 May 2027.

12. Related documents

Counter-signed PDF copy available on request to compliance@glassbreak.io.