Open. Vendor-neutral. Built for the whole industry.
OCSF was announced at Black Hat 2022 by a founding coalition of 18 organisations led by AWS and Splunk, building on schema work done at Broadcom’s Symantec division. The founding group included CrowdStrike, IBM Security, Okta, Palo Alto Networks, Cloudflare, Rapid7, Salesforce, Trend Micro, Zscaler, and others. It defines eight top-level categories of security events — from network activity and identity management to vulnerability findings, remediation actions, and system operations — each subdivided into discrete event classes identified by a numeric class_uid. Every OCSF event carries a mandatory core: class_uid, type_uid, time, severity_id, and a metadata block identifying the originating product. Type-specific fields layer on top of this core.
Unlike proprietary schemas such as Splunk CIM or Elastic ECS, OCSF is not controlled by any single vendor. In November 2024 it became a Linux Foundation project, cementing its position as a neutral, community-governed standard. This is what makes it genuinely useful as a common language: a detection rule written against OCSF data works on any SIEM, data lake, or analytics tool that understands the schema — not just the one it was originally built for.
Why security teams need a common schema
Security teams operate dozens of tools simultaneously. Every data source — EDR, cloud infrastructure, identity provider, network device — produces logs in its own format, with its own field names and semantics. Before OCSF, the translation burden landed on detection and analytics teams: each maintaining a private set of parsers, each detection rule encoding source-specific knowledge that could not be reused elsewhere. OCSF moves that translation to the data pipeline, where it happens once, consistently, at ingest time.
How OCSF organises security events
OCSF organises events into eight top-level categories, each subdivided into event classes with unique numeric identifiers (class_uid). Every event carries a mandatory set of fields — class_uid, type_uid, time, severity_id, and metadata— with class-specific fields layered on top. Profiles add optional field bundles (such as the Malware or Network Proxy profile) that can be applied across multiple event classes. Extensions let vendors add proprietary fields without breaking the core schema.
System Activity
Process creation, file system events, OS-level operations and scheduled tasks.
Findings
Vulnerability findings, detection alerts, compliance results and incident reports.
Identity & Access Management
Authentication events, account changes, group management and authorisation decisions.
Network Activity
DNS queries, HTTP traffic, network connections, packet captures and flow records.
Discovery
Asset inventory, scan results, configuration enumeration and resource discovery.
Application Activity
API calls, web application events, database queries and custom application logs.
Remediation
Remediation actions, patch activity, quarantine events and corrective security responses.
Unmanned Systems
Telemetry and activity from autonomous and unmanned systems, including drones and robotic platforms.
OCSF vs CIM, ECS, and CEF
OCSF is not the first attempt at a common security schema, but it carries the broadest vendor support and is designed to work across tools rather than within a specific platform. Here is how it compares to the schemas you are most likely to encounter.
| Schema | Vendor-neutral | SIEM portability |
|---|---|---|
| OCSF1.7 | Any SIEM or data lake | |
| CIM | Splunk only | |
| ECS | Elastic / OpenSearch | |
| CEF | ArcSight / legacy |
Note: CEF (Common Event Format) defines a log transmission syntax rather than a semantic schema — it specifies how to encode a log line, not what the fields mean. OCSF defines meaning, not encoding.
Who has adopted OCSF
OCSF has attracted adoption well beyond its 18 founding members. AWS builds Amazon Security Lake on OCSF natively — all data ingested into Security Lake is automatically converted to OCSF and stored in Apache Parquet format. As of 2025, the consortium has grown to over 200 participating organisations with 900+ contributors, spanning security vendors, government agencies, and enterprises. The founding 18 were:
Founding members at the August 2022 Black Hat announcement. The consortium now includes 200+ organisations — see ocsf.io for the full current list.
FAQ
- What is OCSF used for?
- OCSF is used to normalise security event data from disparate tools into a single, consistent format. Security teams use it so that detections, dashboards, and analytics work across any data source without rewriting parsers for each one. It underpins schema-agnostic SIEM ingestion, detection portability, and multi-tool correlation.
- Is OCSF the same as CIM?
- No. CIM (Splunk Common Information Model) is a Splunk-proprietary schema that only applies within the Splunk platform. OCSF is vendor-neutral and open-source, designed so any tool, SIEM, or data lake can adopt it. A detection written against OCSF data works regardless of which SIEM you use.
- Do I need OCSF if I already use Splunk?
- OCSF and Splunk are complementary. Normalising to OCSF before data reaches Splunk makes your detections portable — they will work on any SIEM you adopt in future, not just Splunk. It also reduces ingest volume, since you can filter and deduplicate at the OCSF layer before data hits your licence.
- How do I normalise logs to OCSF?
- Normalising to OCSF requires a mapping layer that reads raw log fields and writes them into the correct OCSF class and field structure. This is typically handled by a security data pipeline rather than written by hand, since maintaining 200+ source mappings in-house is impractical at scale.
- What is OCSF schema mapping?
- OCSF schema mapping is the process of translating a source log format — say, an AWS CloudTrail event or a CrowdStrike FDR record — into the correct OCSF event class and field structure. Each source field is assigned to a defined OCSF field, ensuring consistent semantics regardless of origin.
- What version of OCSF is current?
- OCSF 1.7 is the current release. It extended the schema’s coverage of cloud, identity, and application event classes, and refined the profile system. Derwent Labs normalises to OCSF 1.7 out of the box across all connected sources.
- Who created OCSF?
- OCSF was created by a coalition of 18 security vendors led by AWS and Splunk, announced at Black Hat 2022. The founding consortium included CrowdStrike, IBM Security, Okta, Palo Alto Networks, Trend Micro, Zscaler, and others. In November 2024 it became a Linux Foundation project, with 200+ participating organisations contributing to its development.