Skip to main content

Logging and Monitoring Policy

This policy describes what Bunker logs, how those trails are centralised, protected and monitored, and how an anomaly becomes an alert that gets handled. On the observability dimension, it implements the principles of our information security policy and covers controls A.8.15, A.8.16, A.8.17, together with A.5.25 and A.5.28 of the Statement of Applicability.

Status regarding the ISO/IEC 27001 standard

Our controls are self-assessed, aligned with ISO/IEC 27001, not certified by a third party to date. The status of each measure below reflects that self-assessment.

Purpose and scope​

This policy applies to the logs, metrics and traces produced by the platform (console, API, nuage CLI), the managed services we operate and the hosting infrastructure of our three datacenters. It covers their collection, retention, use in monitoring, and their use as evidence after an incident.

Principles​

  • Centralise: a log that stays on the machine that produced it disappears with it. Trails are shipped off the node as they are produced.
  • No secrets in clear text in logs: credentials and tokens are redacted at write time, not cleaned up afterwards.
  • An alert must be actionable: an alert that wakes the on-call without leading to an action is fixed or removed, never tolerated as background noise.
  • Monitor the monitoring: periodic checks emit a heartbeat; their silence raises an alert.
  • Bounded retention: retention is defined and limited, because a log kept without a reason becomes a risk rather than evidence.

Measures​

AreaMeasure
LoggingPer-node agents shipping to a centralised pipeline backed by object storage, plus structured access logs (A.8.15).
Metrics and tracesCentralised metrics and distributed traces surfaced in dashboards shared across the team (Grafana, Mimir, Loki, Tempo) (A.8.16).
RetentionBounded, per-tenant configurable retention: by default in the order of twelve months for logs and three months for metrics.
AlertingRules covering availability, resource saturation, backup freshness and network infrastructure, routed to the on-call rotation (A.8.16).
TriageSecurity events surfaced by monitoring are assessed and classified before escalation (A.5.25).
Log protectionAutomated secret redaction in logs and memory zeroization of keys, so the trail does not itself become a leak (A.8.15).
EvidenceLogs, audit trails and immutable Git history usable after an incident; a formal evidence-preservation procedure still to be formalised (A.5.28, partial).
TimestampingClock synchronisation handled by system default; its formalisation and monitoring are planned, not deployed (A.8.17).

Responsibilities​

  • The CISO (François-Guillaume Ribreau) owns this policy, the alerting rules and the retention periods.
  • The on-call rotation handles alerts, records its decision and closes or escalates per the incident management procedure.
  • Each service owner instruments their component and maintains the alerting rules for their scope.
  • The DPO (Robin Straub) is involved when personal data appears in logs or when access to trails is requested for an investigation.
  • Anyone noticing an anomaly in the logs or an unhandled alert reports it without delay to [email protected].

Status and roadmap​

Logging, activity monitoring and event triage are in place and operational (A.8.15, A.8.16, A.5.25). Two items are declared as lagging. Clock synchronization (A.8.17) currently relies on the system default, with no dedicated formalisation or monitoring, and time correlation across sources is therefore weaker than we intend. Collection of evidence (A.5.28) is partial. The trails exist and are usable, but the preservation procedure that would make them defensible is still to be written. Both are on our roadmap.

Review​

This policy is reviewed at least once a year, after any incident that exposed a monitoring blind spot, and whenever our observability stack changes significantly.

Last reviewed: 31 August 2026.

See also​