Move toward open schemas and open storage formats so the organisation, not the tool, controls how evidence is structured and queried. That preserves migration options, keeps historical data usable across platforms, and reduces the risk that a single vendor’s data model dictates future operating choices. Open data control is now a resilience issue, not just a cost issue.
Why proprietary telemetry formats create strategic lock-in
Proprietary telemetry formats are more than an interoperability annoyance. When evidence is trapped inside a tool-specific schema, the organisation inherits the vendor’s choices about field names, retention behaviour, query model, and export path. That makes it harder to move platforms, compare data across systems, or preserve a long-lived security record that survives tooling changes.
The practical issue is not just readability. Security teams need telemetry that can outlive any one product cycle, support later investigations, and remain usable when the organisation changes vendors, upgrades architectures, or consolidates data sources. Open schemas and open storage formats reduce the chance that a data model becomes a hidden dependency.
That is why evidence portability matters: if the raw events and their structure can be queried outside the original product, the organisation retains operational freedom. If the data can only be understood through one tool, the security programme becomes dependent on that tool’s roadmap, licensing terms, and export quality.
What open schemas and open storage actually preserve
Open schemas preserve semantic control. They let teams define fields, relationships, and normalisation rules in a way that can be documented, reviewed, and reused across platforms. That matters when the same control signal must support detection, hunting, compliance evidence, and incident reconstruction without being remapped every time the stack changes.
Open storage formats preserve historical usability. The best formats are not only exportable, but stable enough that archived records remain queryable after the original system is gone. This is especially important for long retention periods, where the organisation may need to reprocess old telemetry under new detections, new correlation logic, or a different analytics engine.
Open does not mean simplistic. Organisations still need consistent field governance, schema versioning, and documentation for transformations. A well-managed open format gives teams a durable contract for evidence handling, while still allowing enrichment, compression, and pipeline optimisation behind the scenes.
How to avoid replacing one lock-in with another
The main failure mode is treating exportability as a checkbox. If a vendor offers CSV export but drops context, timestamps, relationships, or normalization metadata, the organisation has not truly preserved control. The same is true if the schema is “open” in name but relies on undocumented mappings that only the product can reconstruct.
Organisations should test whether telemetry remains useful outside the source platform. A valid export should support filtering, correlation, and reconstruction without manual rescue work. Where possible, keep a copy of raw events plus a standardised analytical form, so investigations can be replayed without depending on one proprietary parser or dashboard.
Open telemetry design is also a resilience issue. A vendor outage, a licensing change, or a product retirement should not strand historical evidence or force a rushed migration. For teams modernising security data pipelines, NIST SP 800-53 Rev 5 Security and Privacy Controls is a useful reference for anchoring auditability, log management, and configuration discipline around the data lifecycle, while NIST Cybersecurity Framework 2.0 helps frame telemetry portability as part of governance, detection, and recovery rather than a purely technical preference.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST CSF 2.0 | GV.SC-01 — Cybersecurity Supply Chain Risk Management | Proprietary telemetry creates platform dependency and exit risk. |
| PR.DS-01 — Data-at-rest is protected | Open storage formats still need durable data handling and preservation. | |
| RC.RP-01 — Recovery plan is executed | Historical telemetry must remain usable through platform change or recovery. | |
| Recommendation — Define telemetry portability requirements and test vendor exit scenarios. Preserve telemetry in durable, accessible storage with controlled integrity. Ensure telemetry recovery procedures work after tool migration or loss. | ||
| NIST SP 800-53 Rev 5 | AU-11 — Audit Record Retention | Telemetry portability directly affects long-term evidence retention and usability. |
| AU-12 — Audit Record Generation | Open schemas improve consistent event generation and structure. | |
| CM-8 — System Component Inventory | Telemetry architecture needs inventory and control of data sources and outputs. | |
| Recommendation — Retain security telemetry in formats that remain readable over the retention period. Standardise telemetry fields so events can be generated consistently across tools. Inventory telemetry sources and their export formats before approving migrations. | ||
| ISO/IEC 27001:2022 | A.5.15 — Access control | Telemetry access and query control should not depend on a single vendor model. |
| A.8.13 — Information backup | Open storage supports recoverable copies of evidence outside the source system. | |
| A.8.24 — Use of cryptography | Durable telemetry archives often require protected storage and integrity preservation. | |
| Recommendation — Define access rules for telemetry data independently of tool-specific views. Keep recoverable telemetry copies in formats that survive platform change. Protect archived telemetry so evidence remains trustworthy during retention. | ||
Practitioner Guidance
What to prioritise: Start with the telemetry sources that matter most for investigations and compliance evidence, then identify which ones are trapped in proprietary formats. Prioritise the datasets whose loss would most damage detection quality, auditability, or migration options.
What to verify: Test whether you can rehydrate the data outside the original product with acceptable fidelity. If timestamps, identities, event relationships, or enrichment context are lost, the export is not operationally durable enough.
Decision rule: If the organisation cannot describe how it will query its own historical telemetry after a vendor exit, the format is already a dependency risk. Treat open schema and open storage as a control objective for critical telemetry, not as an optional architecture preference.
Practitioner takeaway: The goal is not to eliminate vendors, but to prevent any one vendor from becoming the only interpreter of your security evidence.
Related resources from NHI Mgmt Group
- Should organisations require security telemetry before adopting SaaS tools?
- When should organisations treat agent telemetry as a security control?
- What breaks when security tools cannot parse proprietary engineering file formats?
- How do organisations maintain governance when routing the same telemetry to observability and security tools in parallel?