Glossary
GLOSSARY Data foundations

Canonical Schema

Last updated 27 Jul 2026

A canonical schema is a vendor-neutral data model that every source is mapped into before anything is computed from it. Rather than writing metrics against a particular tool’s fields, you write them against the canonical structure, and each tool gets a mapping.

Tool churn is the reason

Security stacks turn over. An EDR is replaced at renewal. A scanner is consolidated. A SIEM migrates. Over five years most of the estate changes at least once.

Metrics written directly against vendor fields die at each of those transitions. Somebody rewrites the query, the new one counts slightly differently, and the series breaks in a way that is invisible on the chart. See definition drift.

With a canonical schema, the tool change touches the mapping layer and nothing above it. The metric definition is untouched, so the history stays comparable across the swap.

Shape of a security schema

A small number of abstract entity types rather than one per product category. Assets. Alerts. Findings. Incidents. Control evaluations. Identity events and identities. Activity records.

Each carries a core set of fields that any contributing tool can populate, plus room for source-specific attributes that do not force themselves into the shared structure.

The restraint is the hard part. Every additional required field makes some source impossible to map cleanly. Every optional field weakens the guarantee that a metric written against the schema will behave the same across sources.

The tradeoff nobody avoids

Mapping loses detail. A tool’s native severity model may have seven levels and the canonical one four. Something is discarded in the translation, and reconstructing it later means going back to the source record.

The answer is to keep both. Store the source record as received and the canonical projection alongside it. The metric computes from the canonical form. The investigation, when it comes, goes to the original.

Borrowing from OCSF, STIX and ATT&CK

Public schemas exist and are worth borrowing from rather than inventing around. OCSF covers event and telemetry normalization. STIX models threat intelligence objects and relationships. ATT&CK provides a classification taxonomy rather than a schema.

None of them cover the full measurement surface, particularly the non-tool data that a security programme depends on, so most organizations end up with a core borrowed from a standard and extensions of their own.