Governing observability

Reading mode

EngineerDecision-maker

A dated white paper

Regulatory statuses (NIS2 in France, the AI Act postponement) and OpenTelemetry convention versions are recorded as of 16 October 2026. The legal elements are an engineer’s reading: each organization must validate them with its DPO and legal department.

Summary

Observability has become an enterprise asset: it is expensive, it holds sensitive data and it serves as evidence before regulators. Yet in most organizations, nobody owns it. Each team instruments its own way (instrumenting means adding to the code what it needs to produce signals: metrics, logs, traces), each tool imposes its format and the bill arrives without anyone knowing whom to charge it to.

This white paper proposes a governance framework in four pillars, designed to be applied gradually and without depending on a vendor:

• Organization and roles: who decides, who produces the signals, who uses them and who pays for them.
• Standards and OpenTelemetry, the open standard used to produce and carry signals: a common vocabulary, mandatory attributes and configuration-driven pipelines (the chains that collect, transform and route signals).
• Costs and volumes: observability budgets per team, rules on retention (how long data is kept) and sampling (keeping only part of the traces), readable cost allocation.
• Compliance and sovereignty: logs are personal data and regulatory evidence; their lifecycle must be controlled end to end.

Three messages structure the document. First, governance does not add one more committee: it comes down to a set of rules applied automatically in the pipelines. Second, the open standard is the condition for sovereignty: without OpenTelemetry, changing backends (the tools that store and display the data) remains a migration project. Finally, governance is measured; chapter 9 proposes the indicators that show whether it works. The article Your observability has no owner gives a short version.

1. The finding: observability without an owner

Most observability platforms were not designed; they accumulated. One tool for infrastructure, another for applications, a SIEM for security (the tool that centralizes security events), then an APM (an application performance monitoring tool) for a strategic project. Each had its logic when it was adopted. Together, they form a system nobody steers.

Five symptoms recur from one organization to the next:

1. Cost drift. The volume of observability data grows faster than the application estate. Licenses based on ingested volume, meaning the amount of data the tool receives, turn every forgotten debug log into a budget line. The bill is global; allocating it is impossible.
2. Tool sprawl. Several agents, the small collection programs installed on each machine, run on the same host and collect the same data for different destinations. Skills are scattered, contracts pile up.
3. Heterogeneous signals. The same service has three names depending on the team. Attributes (the labels attached to each signal) do not match, cross-cutting queries fail and correlation between traces, metrics and logs stays manual.
4. Sensitive data out of control. Email addresses, customer identifiers or authentication tokens end up in logs. They are then replicated, indexed and kept longer than the business data they describe.
5. Vendor dependency. Proprietary agents, specific query languages and non-exportable dashboards make any exit costly. The question of reversibility is only raised at renewal time.

These symptoms share a common cause: observability is treated as technical tooling, whereas it is an enterprise data flow. An enterprise data flow is governed: you define what comes in, in what form, for what purpose, for how long and at what cost.

2. Defining observability governance

Observability governance is the set of roles, rules and mechanisms that decide which signals are produced, in what form, for which uses, for how long and at what cost. It covers the whole signal lifecycle: instrumentation, collection, transformation, transport, storage, use and deletion.

Its scope

Governed object	Question governance answers
Signals (traces, metrics, logs, resource usage profiles, events)	What do we collect and what do we refuse to collect?
Schemas and attributes	Which vocabulary is mandatory, recommended or forbidden?
Pipelines and agents	Who configures the collectors and how are changes validated?
Storage and retention	For how long, at what level of detail, on which hosting?
Access	Who can read what and how is that access traced?
Costs	Who pays, on what basis, with what budget?
Tools	Which tools are approved, tolerated or being retired?

Its objectives

• Usefulness: every retained signal must serve an identified use (detection, diagnosis, SLO, meaning a quality-of-service objective with a number on it, security, regulatory evidence, capacity).
• Consistency: the same concept bears the same name everywhere, which makes correlation automatic.
• Control: costs and volumes are predictable and attributable.
• Compliance: legal obligations are met by design, not by after-the-fact audit.
• Reversibility: the organization can change backends without re-instrumenting its applications.

What it is not

Governance is not a committee that approves every dashboard. Nor is it a tool choice; it comes before that choice and outlives it. Finally, it is not a constraint imposed on product teams: well designed, it gives them default instrumentation, ready-made dashboards and a readable bill. The guiding principle is the paved road: make the right behavior the easiest one.

3. Pillar: organization and roles

The basic rule is simple: the observability platform belongs to a team; the signals belong to the team that emits them. Without this separation, the platform becomes the dumping ground for decisions nobody made.

The operating model

Three models coexist in organizations. The centralized model entrusts everything to a single team; it guarantees consistency yet quickly becomes a bottleneck. The decentralized model lets each team choose; it is fast at first and ungovernable afterwards. The federated model is the one this white paper recommends: a platform team provides the foundation and the rules; product teams remain responsible for their instrumentation and their alerts.

In the federated model, the platform behaves like an internal product. It has a roadmap, a service catalog, service level commitments and users whose satisfaction it measures.

The roles

Role	Held by	Main responsibilities
Executive sponsor	CIO, CTO or VP Engineering	Arbitrates budgets and priorities, carries the observability policy
Platform lead	Head of Observability or Platform Lead	Owns the roadmap and the catalog; writes and enforces the observability policy
Platform team	SREs and platform engineers	Operates collectors, pipelines and backends; provides instrumentation libraries
Service owner	Tech lead of each product team	Instruments the service, defines its SLOs, manages its observability budget
Observability champion	One volunteer developer per team	Relays the standards, raises needs, supports peers
Security and CISO	Security team	Defines required security logs, their integrity and their access
DPO	Data protection officer	Validates the personal data collected and the retention periods
FinOps	IT financial control	Allocates costs, tracks budgets, warns about drift

The RACI matrix

R: responsible. A: accountable. C: consulted. I: informed.

Decision	Sponsor	Platform lead	Platform team	Service owner	Security	DPO	FinOps
Observability policy	A	R	C	C	C	C	C
Choice of backends and tools	A	R	C	I	C	I	C
Mandatory attributes	I	A	R	C	C	C	I
Instrumenting a service	I	I	C	A/R	I	I	I
Retention rules	I	A	R	C	C	C	C
Personal data filtering	I	A	R	C	C	C	I
Observability budget per team	A	C	C	R	I	I	R
SLOs and alerts of a service	I	I	C	A/R	I	I	I
Access to observability data	I	A	R	C	C	C	I

The observability committee

A light committee meeting once a month is enough. It brings together the platform lead, two or three champions, a security representative, the DPO when needed and FinOps. Its agenda is fixed: schema changes, exception requests, budget overruns, tool retirements. Its decisions are recorded in a versioned register (one that keeps every change), next to the pipeline configuration.

The committee does not approve instrumentation day to day. The rules it adopts are coded into pipelines and CI, the continuous integration that automatically checks every code or configuration change; a rule that cannot be automated should be questioned.

4. Pillar: standards and OpenTelemetry

OpenTelemetry is the recommended reference standard for instrumentation and collection. The choice is strategic rather than technological: it separates producing signals from storing them. Applications are instrumented once; the backend becomes a reversible choice.

Semantic conventions as a common language

The OpenTelemetry semantic conventions define attribute names, types and units. They evolve through versions: v1.44.0 was released in August 2026. Each convention has a stability status (Stable, or Development while its names may still change); that status should guide governance. The HTTP conventions have been stable since v1.23.0 (November 2023), the core of the database conventions since v1.33.0 (May 2025, with MariaDB, SQL Server, MySQL and PostgreSQL). The GenAI conventions, on the other hand, remain at Development status and were moved in June 2026 (v1.42.0) to a dedicated repository to evolve faster.

The resulting governance rule: only Stable attributes can be the basis for an alert, an SLO or a cost allocation. Development attributes are allowed for exploration, with version tracking to anticipate renames.

Mandatory attributes

A small number of resource attributes, the ones that describe where the signal comes from (the service, its version, its environment), must be present on every signal admitted to the platform. A signal that lacks them is rejected or quarantined (set aside for review) by the pipeline.

Attribute	Origin	Governance use
service.name	OTel convention	Service identity, key to any correlation
service.version	OTel convention	Before and after deployment comparison
service.namespace	OTel convention	Grouping by business domain
deployment.environment.name	OTel convention	Separating production from non-production, differentiated retention rules
<org>.team	Internal extension	Signal owner, alert routing
<org>.cost_center	Internal extension	Cost allocation
<org>.data_classification	Internal extension	Sensitivity level, triggers the matching filtering and retention

Internal extensions live in a namespace of the organization’s own (a prefix reserved for it), never in a namespace reserved by OpenTelemetry. They are described in a versioned schema registry, in the same format as the official conventions, which makes it possible to generate documentation and checks automatically.

Configuration-driven pipelines

The reference architecture has two tiers of collectors, the components that receive, transform and forward signals. Agents, as close as possible to the workloads, enrich signals with infrastructure metadata. Gateways, centralized, apply the policies: schema validation, personal data filtering, sampling, routing to backends. Governance becomes executable at the gateway tier.

The configuration of these collectors is treated as code: stored in Git, reviewed, tested in CI and deployed traceably. At scale, a control plane (a central management console) based on the OpAMP protocol, whose specification is still at Beta status, makes it possible to manage a fleet of collectors: inventory, configuration distribution, health status. It answers a question most organizations cannot handle today: which configuration is actually running on each agent?

Automated checks

• In CI: checking that each service declares the mandatory attributes and uses names that comply with the registry.
• At ingestion, meaning when the data is received: rejecting or quarantining non-compliant signals, with a counter per team.
• Continuously: detecting cardinality drift (cardinality is the number of value combinations a metric has, which drives costs up) and unknown attributes, reported to the service owner.

Sources: semantic conventions release notes, HTTP conventions, database conventions, move of the GenAI conventions and their status.

5. Pillar: costs and volumes

The cost of observability is a decision problem rather than a tool problem: every stored signal results from a choice, often implicit, to keep it. Governance makes these choices explicit and ties them to an owner.

Making cost visible

The first step is measurement. The pipeline counts, for each team and each service, the volumes ingested per signal type, metric cardinality and the volume stored per retention tier. These counters are themselves metrics, exposed in a dashboard accessible to all.

Allocation follows the <org>.cost_center attribute. You start with showback: each team sees what it consumes, without being billed. Chargeback, actual billing, only comes once the data is reliable and accepted. Jumping straight to chargeback on disputed figures destroys trust in the approach.

Observability budgets

Each team has a budget expressed in volume or monthly cost, negotiated with FinOps and the platform lead. The budget is a trade-off tool rather than a sanction: a team that wants more detail on a critical service can reduce its debug logs elsewhere. Overruns trigger an alert to the owner, then a committee review if they persist.

The technical levers

Lever	Principle	Watch point
Filtering at the source	Remove signals without an identified use (health checks, the regular calls that verify a service responds, debug logs in production)	Document what is removed so as not to lose a signal useful for diagnosis
Log levels per environment	Debug outside production only, except for temporary, traced activation	Provide an on-demand activation mechanism with automatic expiry
Head sampling	Decision at the start of the trace, at a fixed rate	Simple and cheap, yet blind to rare errors
Tail sampling	Decision after the full trace: errors and slow traces are kept	Needs memory and consistent routing by trace ID across gateways
Cardinality control	Forbid unique identifiers (user, request) as metric labels	Put them in traces or logs, where they cost less
Aggregation	Turn repetitive logs into metrics at the gateway	Keep a raw sample for diagnosis
Tiered retention	Short hot data, aggregated warm data, compressed cold data on object storage	Align tiers with real uses and legal obligations

The retention policy

Retention is decided by use, not by tool. Diagnostic data loses most of its value within a few days; capacity trends are read on aggregates; security and regulatory evidence logs follow imposed durations (see chapter 6). Each data class receives a minimum and a maximum duration, set in advance and justified.

The maximum duration matters as much as the minimum: keeping data too long costs money and creates legal risk.

6. Pillar: compliance and sovereignty

Observability data has a dual legal status. It is an obligation: several texts require logging and the ability to reconstruct an incident. It is also a risk: logs contain personal data and must follow the same principles as the data they describe. Governance must hold both requirements at once.

The applicable regulatory framework

The table cites four texts. The GDPR is the EU regulation on personal data protection, whose application the CNIL, the French data protection authority, spells out. DORA is the EU regulation on digital operational resilience in the financial sector; its RTS are the regulatory technical standards that detail it and ICT risk means risk related to information and communication technology. NIS2 is the EU cybersecurity directive. The AI Act is the EU regulation on artificial intelligence.

Text	What it requires of observability data	Status as of 16 October 2026
GDPR and CNIL recommendation on logging	Log the access and actions of authorized users; keep these logs between six months and one year, up to three years when they serve internal controls; protect the logs themselves	2021 recommendation (deliberation 2021-122), non-binding yet the reference in case of inspection
DORA, RTS on the ICT risk management framework, Article 12	Logging procedures covering access control, capacity management, changes, operations and network traffic; protection against tampering and deletion; detection of logging failures; clock synchronization	Applies to financial entities under the full framework (outside the simplified framework of DORA Article 16)
NIS2	Risk management, incident detection and notification, which assumes usable logging	French transposition through the Résilience bill: the floor debate planned for 7 October 2026 was withdrawn from the agenda the day before, with no new date as of 16 October; working version of the ReCyF framework (v2.5) published by ANSSI on 17 March 2026
AI Act, Articles 12, 19 and 26	Automatic logging of events of high-risk AI systems over their whole lifetime; retention of at least six months	Digital Omnibus (Regulation 2026/1744): application postponed to 2 December 2027 for Annex III systems and to 2 August 2028 for Annex I systems

These texts converge on four requirements: knowing what is logged, keeping it for a justified period, guaranteeing log integrity, controlling who accesses them. A single governance framework can answer them, rather than one project per regulation.

Personal data in observability signals

The data minimization principle applies to observability data. In practice:

• Classify each service by the sensitivity of the data it handles, through the <org>.data_classification attribute.
• Filter at the gateway: mask or hash (replace with a non-reversible fingerprint) email addresses, phone numbers, IP addresses, customer identifiers and tokens, with rules tested in CI like the rest of the configuration.
• Forbid by default capturing request bodies and prompt contents (the instructions sent to an AI model); allow it case by case, after the DPO’s opinion.
• Align log retention with that of the source data: a log should not long outlive the data it describes.
• Trace access to the observability platform itself, which becomes a sensitive system.

Integrity and evidentiary value

A log that can be altered has no value as evidence. Security and compliance logs are separated from operational logs and written to immutable storage for their retention period; their collection chain is itself monitored: a source that goes silent must trigger an alert. Timestamps rely on a documented reference time source.

Sovereignty and reversibility

Observability sovereignty plays out on three levels:

1. Hosting. Logs describe the architecture, potential weaknesses and usage. For sensitive organizations, storing them calls for qualified hosting (SecNumCloud in France, the ANSSI qualification for cloud offerings) or hosting controlled in-house, out of reach of extraterritorial laws.
2. Format. Signals produced with OpenTelemetry can be routed to any compatible backend. The open format is the technical condition for sovereignty.
3. Contractual reversibility. Each contract specifies how data, dashboards and alert rules are exported. An exit plan is written and tested before signing, not at the time of the break-up.

These elements do not constitute legal advice; each organization must validate them with its DPO and legal department.

7. A five-level maturity model

In the field, many organizations sit between levels 1 and 2. The realistic twelve-month goal is level 3 on all four pillars; level 4 is built afterwards; level 5 is only useful for organizations for which observability is a major regulatory or commercial stake.

An organization sits at the level of its weakest pillar: an excellent cost model does not make up for security logs that can be altered.

Level	Organization and roles	Standards and OTel	Costs and volumes	Compliance and sovereignty
1. Endured	No owner; each team chooses its tools	Proprietary formats, free naming	Global bill, not allocated	Personal data present without control; tools’ default retention
2. Tooled	One team operates the tools, without a governance mandate	First OTel collectors; a few local conventions	Volumes measured globally	Security logs identified; retention partly documented
3. Defined	Federated model, published RACI, active observability committee	Mandatory attributes, schema registry, centralized gateways	Showback per team, retention policy by use	Personal data filtering at the gateway, durations validated by the DPO
4. Managed	Platform run as a product, with SLOs and measured satisfaction	Checks in CI and at ingestion, configuration in Git, fleet control plane	Budgets per team, tail sampling, chargeback	Immutable storage for evidence, collection chain monitored, tested exit plan
5. Optimized	Governance evolves from its own indicators	Contribution to open standards; backends interchangeable in practice	Unit cost tracked (per transaction, per service) and decreasing	Compliance demonstrable on demand, without a dedicated audit project

Self-assessment is done pillar by pillar, with evidence: a published document, a pipeline rule, a dashboard. A claim without evidence counts as the level below.

8. Implementation roadmap

Implementation fits in twelve months and targets level 3 on all four pillars. Each phase ends with a verifiable milestone; you do not move on to the next without reaching it.

Phase	Period	Key actions	Exit milestone
1. Lay the foundations	0 to 90 days	Appoint sponsor and lead; inventory tools and volumes; observability charter published; mandatory attributes set	Charter signed and inventory validated
2. Make it executable	Months 3 to 6	Shared OTel gateways; GDPR filtering at the gateway; showback per team; retention validated by the DPO	Level 3 on two pillars
3. Steer	Months 6 to 12	CI and ingestion checks; budgets per team; evidence in immutable storage; tested exit plan	Level 3 on all four pillars

Phase 1: lay the foundations (0 to 90 days)

The goal is to create the mandate and measure the existing situation. You appoint the sponsor and the platform lead, then inventory the tools, deployed agents, ingested volumes and current contracts. The observability charter and the list of mandatory attributes are written with two or three pilot teams, then signed. This phase does not yet change anything in production: it produces the baseline without which no progress can be measured.

Phase 2: make the rule executable (months 3 to 6)

The reference OpenTelemetry gateways are deployed and the pilot teams are connected to them. Personal data filtering and validation of mandatory attributes are applied there. Showback per team is published and the retention policy by use is validated with the DPO and security. The observability committee starts meeting.

Phase 3: steer (months 6 to 12)

Checks move into CI and ingestion for all teams. Observability budgets are allocated and tracked. Security and evidence logs move to immutable storage with their collection monitored. An exit plan is written and tested for each backend. The indicators of chapter 9 become the committee’s agenda.

The main risk of this roadmap is wanting to impose everything from phase 1. Governance that starts with bans before offering a paved road gets bypassed.

9. Governance steering indicators

Governance that is not measured becomes a ritual. A dozen indicators are enough, reviewed monthly in the observability committee and quarterly with the sponsor. Targets are set by each organization from its initial measurement; this table gives their definition, not their value.

Pillar	Indicator	Definition	Expected direction
Organization	Ownership coverage	Share of services whose <org>.team attribute is filled in and valid	Toward 100%
Organization	Platform adoption	Share of production services collected by the reference pipelines	Rising
Organization	Onboarding lead time	Time between a team’s request and its first usable dashboard	Falling
Standards	Schema compliance	Share of ingested signals carrying all mandatory attributes	Toward 100%
Standards	Quarantined signals	Volume rejected or isolated for non-compliance, per team	Falling
Standards	Off-catalog tools	Number of observability tools in service that are not approved	Falling
Costs	Unit cost	Observability cost per business unit (transaction, active user, service)	Stable or falling
Costs	Budget adherence	Share of teams within their observability budget	Rising
Costs	Never-read data	Share of stored volumes without any query over the period	Falling
Compliance	Personal data leaks	Detected occurrences of unfiltered personal data in the backends	Toward zero
Compliance	Retention adherence	Share of data classes whose actual retention follows the policy	Toward 100%
Compliance	Silent critical sources	Number and duration of collection interruptions on security logs	Toward zero

The “never-read data” indicator deserves particular attention: it directly reveals data produced out of habit rather than need. It gives the committee a factual basis for deciding deletions.

Appendices

A. Sample observability charter

This charter fits on one page. It is signed by the sponsor and published next to the schema registry.

1. Every signal admitted to the platform has an identified owner.
2. All retained observability data serves a documented use: detection, diagnosis, SLO, security, regulatory evidence or capacity.
3. Instrumentation uses OpenTelemetry and the semantic conventions; internal extensions are declared in the schema registry.
4. Mandatory attributes are present on every signal; a non-compliant signal is rejected or quarantined.
5. Personal data is minimized at the source and filtered at the gateway; any exception is validated by the DPO.
6. Each data class has a minimum and a maximum retention period, set and justified in advance.
7. Each team has an observability budget and sees its consumption.
8. Collector configuration is versioned, reviewed and deployed traceably.
9. Security and evidence logs are protected against tampering; their collection is monitored.
10. Every observability tool is approved and has an exit plan.

B. Service onboarding checklist

• Service owner and team declared
• Classification of the data handled validated
• OpenTelemetry SDK (the library built into the code) or automatic instrumentation in place
• Mandatory attributes filled in and checked in CI
• Signals routed through the reference gateways
• Personal data filtering rules tested on real samples
• Log levels per environment configured
• Observability budget allocated and consumption dashboard shared
• At least one SLO defined, with its alerts routed to the team
• Runbook (procedure sheet) linked to each alert

C. Glossary

Term	Definition
Cardinality	Number of distinct combinations of attribute values for a metric; the main cost factor of time series databases
Chargeback	Actual billing of observability costs to the consuming teams
Collector	OpenTelemetry component that receives, transforms and exports signals; deployed as an agent or a gateway
Semantic conventions	OpenTelemetry registry of standardized attribute names, types and units
Tail sampling	Deciding whether to keep a trace after observing it in full
OpAMP	OpenTelemetry protocol for remotely managing a fleet of agents
Showback	Displaying consumption per team, without billing
SLO	Service level objective, expressed on a measured indicator (SLI)

D. References

• CNIL recommendation on logging measures (in French)
• CNIL, deliberation 2021-122 of 14 October 2021 (Légifrance, in French)
• DORA, Delegated Regulation (EU) 2024/1774, Article 12: logging (EUR-Lex)
• Résilience bill, legislative file (Assemblée nationale, in French)
• Postponement of the Résilience bill debate (Next, updated 6 October 2026, in French)
• The NIS 2 directive (ANSSI, in French)
• AI Act, Regulation (EU) 2024/1689 (EUR-Lex) and Article 12: record-keeping (European Commission)
• Digital Omnibus, Regulation (EU) 2026/1744 (EUR-Lex)
• OpenTelemetry: semantic conventions release notes
• OpenTelemetry: GenAI conventions, Development status
• OpenTelemetry: OpAMP specification

BridgesWhat this page changes beyond the technical team.

BusinessValue, cost, risk

Showback first, chargeback later: observability budgets per team turn a global bill into readable trade-offs.

OrganizationWho decides, who owns

The federated model, the RACI matrix and a monthly committee give a written answer to “who decides what”.

PeopleTeams, on-call, skills

One observability champion per team relays the standards; the paved road keeps governance from being experienced as policing.

Business linesProduct, finance, risk, customer

The DPO validates the personal data collected and the retention periods; the sample charter fits on one page signed by the sponsor.

Why bridges matter →